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Abstract 

Chaosnet  is  a  local  network ,  that  is,  a  system  for  communication  among  a  group  of 
computers  located  within  about  1000  meters  of  each  other.  Originally  developed  by  the  Artificial 
Intelligence  Laboratory  as  the  internal  communications  medium  of  the  Lisp  Machine  s>stcm,  it 
has  since  come  to  be  used  to  link  a  variety  of  machines  around  MIT  and  elsewhere. 

This  memo  describes  both  the  hardware  and  the  software  protocols.  It  is  intended  to  he  the 
definitive  documentation  for  Chaosnet. 
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Introduction 


1.  Introduction 


Chaosnet  is  a  local  network ,  that  is,  a  system  for  communication  among  a  group  of 
computers  located  within  one  or  two  kilometers  of  each  other.  I  he  name  ('haosnet  refers  to  the 
lack  of  any  centralized  control  element  in  this  network. 

Chaosnet  was  originally  developed  in  1975  by  the  Artificial  Intelligence  Laboratory  of  die 
Massachusetts  Institute  of  Technology  as  the  internal  communications  medium  of  the  1  tsp  Machine 
system  (CIIINUAL,  AIM444].  It  has  since  come  to  he  used  to  link  a  satiety  ot  machines  around 
the  Institute.  Chaosnets  also  exist  at  several  other  universities  and  research  laboratories. 

The  l  isp  Machine  system  is  a  multi-processor  in  which  each  active  user  is  assigned  a 
"personal"  computer  consisting  of  a  medium-scale  processor,  a  suitable  amount  of  memory,  and  a 
swapping  disk.  Liles  arc  stored  in  a  central  file-system  accessed  through  Chaosnet.  !  his  shared 
file-system  retains  the  traditional  advantages  of  a  time-sharing  system,  munch  inter-user 
communication,  shared  programs,  and  centralized  backup  and  maintenance.  At  the  same  time,  by 
giving  each  active  user  his  own  processor,  the  Lisp  Machine  system  is  much  more  capable  than  a 
time-sharing  system  at  executing  l  isp  programs  several  million  words  in  si/e  elliuently  and  with 
rapid  interactive  response.  Because  Chaosnet  is  taking  the  place  of  the  file  disk  in  a  conventional 
system,  it  must  be  fast  (both  in  response  and  in  throughput),  it  must  he  tellable  (ties  is  the 
reason  why  there  is  no  centralized  control),  and  it  must  allow  connection  of  several  dozen 
machines.  However,  it  does  not  need  to  operate  over  long  distances.  Chaosnet  is  used  to  access 
other  shared  resources  in  addition  to  the  file  system;  these  include  printets,  tape  dtives,  and  one- 
of-a-kind  specialized  processors  and  I/O  devices. 

The  system  goals  for  Chaosnet  were  primarily  simplicity  and  high  performance.  The 
performance  is  achieved  by  starting  with  a  very  high  speed  transmission  medium  and  operating  it 
in  a  simple,  low-overhead  fashion,  rather  than  by  using  unusually  clever  algotithms.  Of  course 
one  has  to  be  careful  to  avoid  algorithms  which  are  so  simple  that  they  don't  work  or  waste  so 
much  of  the  transmission  medium  that  performance  is  impacted.  Simplicity  was  important  not 
only  to  improve  performance,  but  because  Chaosnet  connects  a  diverse  set  nl  machines,  and 
hence  had  to  have  several  implementations  all  of  which  require  maintenance  in  propmtiou  to  their 
complexity. 

Simplicity  of  design  also  aids  greatly  in  maintenance  and  management  of  the  net  wink  itself, 
which  has  proven  to  be  a  non  trivial  task  in  a  network  involving  a  variety  of  machines  and  used 
by  a  variety  of  groups,  even  within  the  single  institution  of  Mi  l.  It  is  important  to  he  able  to 
isolate  an  apparent  failure  of  die  whole  network  to  the  cable  or  to  a  paitiuilar  host's  hat dw are  or 
software  as  rapidly  as  possible. 

The  design  of  Chaosnet  was  greatly  simplified  by  ignoring  problems  inelev.mt  to  local 
networks.  Chaosnet  i uninins  no  special  provisions  for  filings  such  as  low  speed  links,  noisy  (very 
high  error-rate)  links,  multiple  paths,  and  long  distance  links  with  Simula  ant  uansii  time.  Ibis 
means  that  Chaosnet  is  not  paiticulailv  suitable  for  use  «u  toss  the  continent  ot  in  satellite 
applications.  Ch;ioMi»  t  also  makes  no  attempt  to  provide  unnorev,  n\  fealnies  ■  at?  li  as  multiple 
levels  o|  seivite  or  vuue  lonimiinie.ition  (oihct  than  by  end  to  end  enuypimn) 
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Chaosnet  was  largely  inspired  by  the  pioneering  work  on  local  networks  at  Xerox  PARC 

[ErHHRNET]. 

Chaosnet  consists  of  two  parts — the  hardware  and  the  software — which,  while  logically 
separable,  were  designed  for  each  other.  The  hardware  provides  a  carrier-sense  multiple-access 
structure  very  similar  to  the  PARC  Ethernet.  Network  nodes  contend  for  access  to  a  cable,  or 
ether,  over  which  they  may  transmit  packets  addressed  to  other  network  nodes.  The  software 
defines  higher-level  protocols  in  terms  of  packets.  These  protocols  can  be  (and  arc)  used  with 
media  other  than  die  Chaosnet  cable,  and  with  multiple  interconnected  cables.  The  software 
contains  ideas  borrowed  from  Ethernet  [ETHERNET],  TCP  [TCP],  and  Arpanet,  with  some 
original  ideas  and  modifications. 
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2.  Hardware  Protocol 

2.1  The  Ether 

The  transmission  medium  of  Chaosnet  is  called  the  ether.  Physically  it  is  a  coaxial  cable,  of 
the  semi-rigid  1/2  inch  low-loss  type  used  for  cable  TV,  with  75-ohm  termination  at  both  ends. 
At  each  network  node  a  cubic  transceiver  is  attached  to  the  cable.  A  IO  meter  flat  cable  connects 
the  transceiver  to  an  interface  which  is  attached  to  a  computer’s  I/O  bus.  A  network  node 
consists  of  this  transceiver  and  interface  and  a  computer  which  executes  a  certain  piece  of  software 
called  the  Network  Control  Program  (NCP),  which  manages  and  controls  Chaosnet,  in  addition  to 
whatever  application  software  justifies  its  existence  in  the  first  place. 

One  network  node  at  a  time  may  seize  the  ether  and  transmit  a  packet,  which  arrives  at  all 
other  nodes;  each  node  decides  in  hardware  whether  to  ignore  the  packet  or  to  receive  it.  A 
single  ether  must  be  a  linear  cable;  it  may  not  contain  branches  nor  stubs,  and  the  ends  may  not 
be  joined  into  a  circle.  ’The  maximum  length  of  an  ether  cable  is  about  1  kilometer.  This  is 
determined  by  dispersion  and  by  DC  attenuation.  The  maximum  number  of  nodes  on  a  single 
ether  is  probably  a  few  dozen.  TTiis  is  determined  by  degradation  of  the  electrical  properties  of 
the  cable  by  the  connectors  used  to  attach  the  transceivers. 

ITic  maximum  length  of  an  ether  could  be  increased  by  using  repeaters  (bidirectional  digital 
amplifiers  joining  two  pieces  of  cable).  In  practice  this  is  not  done.  Instead,  the  protocol 

provides  for  multiple  ethers,  joined  together  by  nodes  called  bridges  which  relay  packets  from  one 
ether  to  another.  A  bridge  is  typically  a  pdpll  computer  with  two  or  more  network  interfaces 

attached  to  it.  A  bridge  node  usually  performs  other  tasks  as  well,  such  as  interfacing  terminals. 

Bridges  attach  other  network  media  as  well  as  ethers;  some  computers  connect  to  the  network 
through  their  manufacturer’s  high  speed  compiitcr-to-computcr  interface  to  a  nearby  bridge,  rather 
than  being  interfaced  directly  to  an  ether.  Asynchronous  lines  have  also  been  used  as  Chaosnet 
media. 

The  form  of  information  on  the  ether,  the  transceiver  and  interface  hardware,  and  the 

protocols  which  control  who  may  seize  the  ether  arc  described  in  the  following  sections. 


2.2  Packets 

The  basic  unit  of  transmission  is  called  a  packet.  ’Hi is  is  a  sequence  of  up  to  40.12  data  bits, 
plus  48  bits  of  header  information  used  by  the  hardware.  Packets  bits  are  normally  grouped  into 
16-bit  words.  The  division  of  a  transmitted  bit  stream  into  packets  provides  a  conveniently-sized 
unit  for  resource  allocation  and  error  control.  The  job  of  die  hardware  is  to  deliver  a  packet 
from  one  node  to  another.  Software  protocols  define  the  meaning  of  the  data  hits  itt  a  packet, 
manage  the  huulware,  compensate  for  imperfections  of  the  hardware,  and  piovide  more  useful 
services  than  simple  transmission  of  packets  from  one  computer  to  another. 

The  hardware  header  consists  of  three  16  bit  words,  called  dcstinuthm.  source,  and  check. 
The  source  identifies  the  node  winch  transmitted  this  packet  onto  this  ether  This  is  not 
nccessnul}  i he  original  source  of  the  message,  since  it  may  have  originated  on  a  diileient  ether. 
The  destination  identities  the  node  whi.  h  is  intended  to  receive  (his  packet  horn  this  ether.  This 
is  not  neccv  aiily  the  final  destination  of  the  mev.age;  it  mav  he  a  bridge  which  should  iclay  the 
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packet  to  another  ether,  whence  it  will  eventually  reach  its  final  destination.  'Hie  check  word  is  a 
cyclic  redundancy  checksum,  generated  and  checked  by  hardware,  which  detects  errors  in 
transmission  through  the  ether,  cntircly-spurious  packets  created  by  noise  on  the  cable,  and 
memory  errors  in  the  transmitting  and  receiving  packet  buffers. 

ITie  software  protocol  is  also  based  on  packets,  taking  128  of  the  data  bits  as  a  software 
header.  This  is  described  in  section  3.5,  page  12. 


2,3  The  Transceiver 

Everyone  who  connects  to  the  ether  docs  so  through  a  transceiver,  which  is  a  small  box 
which  mounts  directly  on  the  cable  via  a  UHF  connector  and  a  T-joint.  All  nodes  use  identical 
transceivers  (the  interface  varies  depending  on  what  computer  it  is  designed  to  interface  to).  The 
transceiver  contains  the  analog  portion  of  the  interface  logic,  provides  ground  isolation  between 
the  ether  cable  and  the  computer,  and  contains  some  protective  circuitry  designed  to  prevent  a 
malfunctioning  program  or  interface  from  continuously  jamming  the  ether.  (If  it  were  to  be 
redesigned,  it  ought  to  contain  even  more  protective  circuitry,  since  there  are  some  possible 
interface  failures  that  can  get  past  the  protection  and  render  the  ether  unusable.) 

The  transceiver  receives  a  differential  digital  signal  from  the  computer  interface  and  impresses 
it  onto  the  cable  as  a  level  of  about  8  volts  for  a  1,  or  0  volts  (open  circuit)  for  a  0,  through  a 
very  fast  VMOS  power  FIT.  When  the  cable  is  idle  it  is  held  at  0  volts  by  the  terminations. 
Tltis  simple-minded  unipolar  scheme  is  adequate  for  the  medium  cable  lengths  and  transmission 
speeds  we  arc  using.  'Hie  transceiver  monitors  the  cable  by  comparing  it  against  a  reference 
voltage,  and  returns  a  differential  signal  to  the  interface.  In  addition,  it  detects  interference 
(another  transceiver  transmitting  at  the  same  time  as  this  one)  and  informs  the  interface. 

The  transceiver  includes  indicators  (light-emitting  diodes)  for  power  OK,  transmitted  data, 
received  data,  and  interface  attempting  to  jam  the  ether.  A  test  button  simulates  an  input  of 
continuous  Vs  from  the  interface,  which  should  light  all  the  lights  (dimly)  if  the  transceiver  is 
working.  These  indicators  and  the  test  button  are  useful  for  rapidly  tracking  down  network 
problems.  TTic  transceiver  requires  its  own  power  supply  mounted  nearby;  one  power  supply  can 
service  three  transceivers  if  they  arc  all  adjacent.  High-voltage  isolation  between  the  cable  and  the 
computer  is  provided  by  optical  isolators  within  the  transceiver. 


2.4  The  Interface 

TTic  interface  is  typically  a  wire-wrap  board  containing  about  120  Til.  logic  chips,  which 
plugs  into  the  I/O  bus  of  a  computer  and  connects  it  to  the  ether  (through  a  transceiver.)  The 
interlace  implements  the  hardware  protocols  described  in  the  next  section,  buffers  incoming  and 
outgoing  packets,  generates  and  checks  checksums,  and  interrupts  the  host  computer  when  a 
packet  is  to  be  read  out  of  the  receive  packet  buffer  or  stored  into  the  transmit  packet  buffer. 
These  packet  buffers  shield  the  host  computer  from  the  high  speed  of  data  transmission  on  the 
table.  Instead  of  basing  to  produce  bits  at  a  high  rate,  the  host  can  produce  them  at  a  lower 
rate,  collect  them  into  a  packet,  and  then  tell  the  interface  to  transmit  the  packet  in  a  single 
burst  of  high-speed  transmission. 
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Interfaces  currently  exist  for  Lisp  machines,  for  DKC  LSI-11  micro-computers,  and  for  the 
DKC  Unibus  [UNIBUS],  which  allows  Chaosnet  to  be  attached  to  pdpll’s,  VAX’s,  and  the 
peripheral  processors  of  most  pdplO’s.  Programming  documentation  for  this  compatible  family  of 
interfaces  appears  later  in  this  paper. 

Interfaces  for  other  computers  are  likely  to  exist  in  the  future.  Hie  existing  interface  design 
docs  not  make  any  unusual  special  demands  of  its  host  computer  and  should  be  easily  adaptable 
to  other  architectures. 

2.5  Hardware  Protocols 

The  purpose  of  these  protocols  is  to  deliver  packets  intact  from  one  node  to  another  node  on 
the  same  ether,  with  fairly  high  probability  of  success,  and  to  guarantee  to  give  an  error 

indication  or  lose  the  packet  entirely  if  it  is  not  delivered  intact.  An  additional  purpose  is  to 

provide  high  performance  and  not  to  bog  down  when  subjected  to  a  heavy  load. 

Bits  are  represented  on  the  ether  using  a  technique  which  is  called  Upright  Biphase  NRZI. 
Each  bit  cell,  which  is  approximately  250  nanoseconds  long,  begins  with  a  transition  in  state, 
from  high  to  low  or  from  low  to  high.  This  transition  marks  the  beginning  of  a  bit  cell  and 
provides  sclf-clocking.  3/4  of  the  way  through  the  bit  cell,  the  state  of  the  cable  is  sampled; 
high  represents  a  1  and  low  represents  a  0.  If  the  bit  being  represented  is  the  same  as  the 
previous  bit,  there  will  be  one  transition  at  the  beginning  of  the  bit  cell  and  a  second  in  the 
middle  of  the  bit  cell.  If  the  bit  being  represented  is  the  opposite  of  the  previous  bit,  there  will 
be  no  transition  in  the  middle  of  the  bit  cell  since  the  clock  transition  will  have  set  the  cable  to 
the  desired  state.  The  AC  frequency  of  the  signal  on  the  cable  varies  between  1/2  die  bit  rate 
and  the  full  bit  rate.  The  information  bit-rate  is  4  million  bits  per  second. 

The  sclf-clocking  Feature  allows  for  slight  variations  in  transmission  and  cable  propagation 

speed.  However,  since  die  3/4  of  a  bit  cell  delay  is  a  fixed  delay,  only  modest  variations  in 
speed  can  be  tolerated.  A  crystal  clock  is  used  as  die  source  of  die  transmit  timing  in  die 
interface. 

Since  there  is  always  at  least  one  state-transition  per  bit  cell,  the  suites  where  die  ether 

remains  high  or  low  for  an  appreciable  time  are  available  for  non-data  uses.  If  the  ether  remains 
low  for  more  than  about  two  bit  cells,  it  is  considered  to  be  not-busy.  This  condition  marks  die 
end  of  a  packet  and  allows  someone  else  to  transmit.  Note  that  if  no  transceivers  arc  active,  the 
terminations  will  hold  the  ether  low. 

If  the  ether  remains  high  for  about  two  bit  cells,  this  is  an  "abort  signal”.  Abort  signals  are 
used  for  two  purposes.  II'  the  transceiver  detects  a  collision  (two  nodes  trying  to  transmit  at  die 
same  time),  each  transmitting  interface  ceases  to  transmit  and  sends  an  aboil  signol  (lour  bit  cells 
long),  which  tells  all  receivers  to  ignore  the  aborted  packet  and  ensures  that  the  othei  transmitter 
also  aborts.  Tims  when  a  collision  occurs,  the  ether  is  cleared  as  soon  as  possible  to  help  prevent 
long  dc'iifi*.  under  conditions  of  heavy  load.  The  oilier  use  for  the  abort  signal  is  m  hardware 
How-control.  When  a  uxeiving  interface  determines  that  an  incoming  packet  is  addussed  to  it, 
but  its  receive  IniHer  already  contains  a  packet,  it  sends  an  abort  signal  which  causes  the 
transmitter  to  stop,  this  saws  the  dual  pm  pose  of  immediate!)  informing  the  iiaism  iiei  that  its 
messtee  did  not  get  ihiouch,  and  piv\iutmp  the  ether  from  being  lied  up  while  a  long  packet  is 
transmitted  which  the  receiver  cannot  receive. 
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Packets  arc  transmitted  over  the  ether  in  reverse  bit-order,  for  hardware  convenience.  The 
three  header  words,  which  to  the  software  appear  to  be  at  the  end  of  the  packet,  arc  transmitted 
first,  in  the  order  check,  source,  destination.  The  data  words,  in  reverse  order,  follow.  Words 
are  transmitted  least-significant  bit  first.  Of  course,  the  software  need  not  be  aware  of  this 
reversal;  packets  arrive  at  the  destination  in  the  same  form  as  they  were  created  by  the  source. 
At  the  end  of  the  packet,  an  extra  zero  bit  is  appended  to  bring  the  ether  to  the  low  state  so 
that  an  extra  spurious  clock-transition  will  not  be  generated  when  it  goes  idle.  This  bit  is  stripped 
off  by  the  interface  and  is  never  seen  by  software. 

The  check  word  is  used  for  error  detection,  as  described  above.  The  source  word  is  made 
available  to  the  software,  which  ignores  it  in  most  eases,  and  also  serves  to  synchronize  the  clocks 
in  the  collision-avoidance  mechanism  which  is  described  below.  The  destination  word  is  compared 
by  each  receiver  against  its  own  address.  If  they  match,  or  if  the  destination  is  zero,  or  if  the 
software  selects  the  "match  any  destination"  mode,  the  packet  is  placed  in  the  receive  packet 
buffer  and  the  host  computer  is  interrupted.  The  zero  destination  feature  is  used  for  "broadcast" 
messages.  Note  that  a  receiver  whose  packet  buffer  is  full  will  only  generate  an  abort  signal  if  the 
packet  was  specifically  addressed  to  it. 

2.6  Ether  Contention 

Chaosnet  has  no  centralized  control  element;  when  a  network  node  has  a  message  to  transmit, 

its  interface  seizes  the  ether  and  transmits  a  packet.  Hie  time  when  it  seizes  the  ether  is 

determined  only  by  state  inside  that  particular  interface  and  by  the  local  state  of  the  cable  at  the 
point  where  that  interface’s  transceiver  is  attached. 

If  two  interfaces  should  decide  to  seize  the  ether  and  transmit  at  the  same  time,  their 

transmissions  will  interfere  and  no  useful  information  will  be  transmitted.  'This  is  called  a 

collision.  Collisions  arc  the  principal  limitation  on  the  bandwidth  of  a  heavily-loaded  ether-type 
network,  and  should  be  avoided.  (However,  neither  PARC’s  network  nor  Mil's  network  has  yet 
been  operated  with  a  heavy  enough  load  to  make  collisions  really  significant.) 

Chaosnet  uses  a  novel  collision  avoidance  technique.  First  of  all,  an  interface  will  never 
initiate  transmission  unless  the  ether  is  seen  to  he  not  busy,  i.c.  it  has  been  in  the  low  state  for 
some  time.  ITiis  ensures  that  collisions  can  only  occur  near  the  beginning  of  a  packet.  Once 
transmission  of  a  packet  has  gotten  well  started,  the  ether  is  effectively  "seized"  (all  interfaces 
realize  that  it  is  busy)  and  transmission  will  continue  successfully  through  to  the  end  of  the 
packet.  rl  he  amount  of  ether  transmission  time  wasted  by  a  collided  packet  is  therefore  limited  to 
the  round-trip  cable  propagation  delay.  This  technique  is  tailed  carrier  sense. 

Secondly,  the  hardware  uses  a  time-division  technique  to  attempt  to  prevent  tv\o  intet faces 
ft  tun  initiating  transmission  at  the  same  time.  This  technique  should  pieu  nt  essentially  all 
collisions  while  imposing  only  a  modest  delay  in  the  initiation  of  transmission.  It  is  designed  so 
that  it  works  better  as  the  Mad  on  the  ether  increases;  the  wasted  lime  between  packets  and  the 
relative  into  of  collisions  both  decrease. 

The  basic  idea  is  that  each  interface  is  assigned  a  lime  slot,  or  turn,  according  to  its  address. 
It  may  only  initiate  tiansmtssion  during  it‘  turn.  I  he  lour;  are  spaced  far  rtmugh  apart  that  if 
one  interlace  inmate,  transmission.  c\or\  other  inleilace  will  perceive  that  the  ether  F  busy  hv  the 
time  its  oval  turn  ai lives,  and  will  not  initiate  mi  inteileime  Iran  mission  I  lath  mmifn  e  contains 
a  lime  slot  uninici  which  counts  while  the  elhei  is  not  busy,  keeping  track  of  whose  turn  it  is. 
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Each  packet  synchronizes  the  counters  in  all  of  die  interfaces  by  setting  them  from  the  source 
address  of  dial  packet;  at  the  time  the  packet  was  transmitted,  it  must  have  been  the  turn  of  the 
interface  that  transmitted  it. 

Another  way  to  think  of  this  is  to  make  an  analogy  with  ring  networks.  One  can  imagine  a 
virtual  token  which  passes  down  the  cable  until  it  gets  to  the  end,  dicn  jumps  to  the  beginning  of 
the  cable  and  repeats.  An  interface  may  only  initiate  transmission  at  the  instant  the  token  passes 
by  it.  When  an  interface  transmits,  the  token  stops  moving  and  remains  at  that  interface  until  the 
end  of  the  packet,  whereupon  it  continues  down  the  cable,  passing  every  other  interface,  giving 
diem  each  a  chance  to  transmit  before  letting  the  first  interface  transmit  a  second  packet. 

The  token  is  not  represented  by  any  physical  transmission  on  the  cable.  'Hi at  would  constitute 
a  form  of  centralized  control,  and  would  lead  to  reliability  problems  if  the  token  was  lost  or 
duplicated.  Instead,  every  interface  contains  a  time-slot  counter  which  keeps  track  of  where  the 
token  is  thought  to  be.  Every  time  a  packet  is  transmitted  these  counters  arc  brought  up-to-date. 
The  token  cannot  be  lost  because  a  counter  by  its  nature  eventually  returns  to  all  previous  states. 
It  docs  not  matter  if  the  token  is  duplicated  (i.c.  the  counters  lose  synchronization)  occasionally, 
since  this  will  only  cause  collisions,  which  we  know  how  to  detect  and  deal  with,  and  since  the 
first  successful  transmission  will  resynchronizc  all  counters.  The  basic  mechanism  of  the  ether 
network  with  contention  and  collisions  is  known  to  work,  and  the  collision-avoidance  scheme  is  an 
added-on  optimization  which  improves  performance  without  changing  the  basic  mechanism. 

There  is  a  finite  propagation  delay  time  between  interfaces,  and  this  time  is  not  small 
compared  with  the  bit-rate  of  Chaosnet,  nor  when  compared  with  the  desirable  length  of  a  time 
slot.  This  time  consists  of  the  delay  in  the  cable,  about  5  nanoseconds  per  meter,  and  the  delay 
through  the  two  transceivers,  about  220  nanoseconds.  This  propagation  delay  means  that  the  time- 
slot  counters  in  two  different  interfaces  cannot  be  exactly  synchronized,  and  dial  when  interface  A 
initiates  transmission  interface  B  will  not  instantaneously  sec  that  the  ether  is  busy.  Special 
relativity  tells  us  that  in  fact  the  concept  "exactly  synchronized"  is  meaningless.  Since  die  two 
time-slot  counters  arc  not  in  die  same  place,  the  only  way  we  can  compare  them  is  to  send  a 
message  from  one  to  the  other,  through  die  ether,  containing  the  reading  of  the  counter.  But  this 
message  takes  non-zero  time  to  get  there,  so  the  counter-reading  it  contains  is  wrong  by  the  time 
it  is  compared  against  the  other  counter!  We  in  fact  do  send  messages  containing  counter 
readings;  die  source  address  in  a  packet  equals  the  reading  of  the  time-slot  counter  in  the 
interface  diat  sent  it — at  the  time  it  was  sent.  Since  die  network  nodes  are  not  in  relative  motion, 
we  can  measure  the  distance  between  them  and  use  that  information  to  improve  their 
synchronization. 

What  we  arc  trying  to  do  is  to  prevent  collisions.  This  u.sms  that  if  interface  A  starts 
transmitting  a  packet  in  its  turn,  then  by  the  time  interface  B  thinks  that  its  own  turn  has  arrived, 

it  must  perceive  the  ether  as  busy.  We  will  assign  addresses  (and  hence  time  slots)  and  set  the 

length  of  a  time  slot  in  such  a  way  that  this  will  happen.  Suppose  die  maximum  delay  through 

the  ether  between  A  and  II  is  t.  This  would  be  the  delay  for  one  of  them  sending  a  packet  to 

the  other;  the  delay  between  A’s  receipt  of  a  third  party's  packet  and  It's  receipt  ot  dial  packet  is 
less,  especially  if  the  third  party  is  between  A  and  II  on  the  cable  1  hen  the  maximum  perceived 
difference  between  a  clock  at  A  and  a  dock  at  11  is  .?/:  if  a  message  is  sent  tn>m  B  to  A 
synchroni/iiit’.  the  clocks,  and  then  a  message  is  sent  from  A  to  11  cnnlaimin*  .Vs  cltsk  reading,  at 
B  this  clock  iv.»dinu  will  lv  slow’  by  ?t. 
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When  a  packet  transmitted  by  A  arrives  at  B,  B’s  clock  may  read  as  much  as  2t  earlier  or 

later  than  A’s  turn,  depending  on  the  transmission  direction  of  the  last  synchronizing  message.  In 

order  to  guarantee  that  B’s  turn  has  not  yet  happened,  the  time  between  any  of  A’s  turns  and 

any  of  B’s  turns  must  always  be  at  least  2t f  twice  the  maximum  propagation  delay  through  the 

ether  between  A  and  B.  This  is  the  important  idea!  We  cause  this  to  be  true  by  assigning 
addresses  starting  at  one  end  of  the  cable;  each  node’s  address  is  the  previous  node's  address  plus 
twice  the  propagation  delay  between  them,  divided  by  the  length  of  a  turn.  It  is  easy  to  sec  that 
if  this  is  done  for  all  adjacent  pairs,  the  condition  will  automatically  be  true  fur  non-adjacent 
pairs  as  well.  When  we  get  to  the  end  of  the  cable,  we  must  assign  a  number  of  empty  slots 
equal  to  twice  the  propagation  delay  of  the  full  length  of  cable,  to  provide  the  necessary 
separation  between  the  turns  of  the  two  nodes  at  the  ends  of  the  cable. 

The  virtual  token  travels  through  the  network  at  a  substantially  slower  speed  than  a  real  signal 
such  as  a  packet;  in  the  fastest  case,  when  nodes  are  very  far  apart,  it  travels  at  just  half  the 
speed  of  a  real  signal.  Since  a  Chaosnet  ether  has  the  geometry  of  a  line,  as  compared  to  the 
ring  net's  circle,  the  virtual  token  is  also  slowed  down  by  the  need  to  return  from  the  end  of  the 
cable  to  die  beginning.  This  slower  speed  of  the  token  is  die  price  one  pays  for  the  increased 
robustness  of  Chaosnet  as  compared  with  a  ring  network.  In  a  real  system,  we  slow  the  token 
down  even  more  to  provide  a  margin  of  safety.  The  speed  of  the  network  is  not  significantly 
affected  by  die  slow  token,  since  the  interval  between  packet  transmissions  by  a  single  node  is 
much  longer  than  the  round-trip  time  of  the  token.  Indeed,  if  the  network  is  being  used 
primarily  for  file  transfer,  and  hence  the  packets  arc  large,  the  transmission  time  alone  for  a 
typical  packet  is  several  times  the  round-trip  time  of  die  token.  A  typical  value  for  the  token’s 
round-trip  time  is  64  microseconds. 

In  spite  of  all  this,  sometimes  collisions  will  occur  anyway.  If  the  cable  has  been  idle  for  a 
long  time,  the  various  clocks  will  have  lost  synchronization.  If  a  source  address  is  corrupted  by  a 
transmission  error,  any  interface  that  secs  that  source  address  will  set  its  dock  to  an  incorrect 
value.  Sometimes  a  packet  will  collide  with  random  noise  rather  than  another  legitimate  packet. 
In  addition,  the  transmitter  docs  not  distinguish  receiver-busy  aborts  from  real  collisions. 

When  a  collision  docs  occur,  wc  recover  from  it  (in  software)  by  retransmitting  the  packet 
again  a  couple  of  times,  hoping  that  wc  will  be  lucky  enough  not  to  have  another  collision,  or 
that  the  receiver  will  soon  clear  its  packet  buffer.  This  retransmission  is  done  by  the  software,  not 
the  hardware,  since  the  hardware  destroys  die  packet  in  its  packet  buffer  in  the  process  of 
transmitting  it.  But  if  collisions  continue  to  occur,  we  give  up  and  let  somebody  else  have  the 
ether.  The  packet  is  lost.  A  higher  level  of  protocol  will  soon  realize  that  it  has  been  lost  and 
retransmit  it.  Wc  assume  that  there  is  enough  randomness  in  the  higher-level  software  dial  the 
two  nodes  which  originally  collided  will  not  collide  again  on  the  retransmission  by  deciding  to 
retransmit  at  precisely  the  same  instant. 
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3.  Software  Protocol-World  View 

The  purpose  of  the  basic  software  protocol  of  Chaosnet  is  to  allow  high-speed  communication 
among  processes  on  different  machines,  with  no  undetected  transmission  errors.  The  speed  for  file 
transfers  in  real-life  circumstances  was  to  he  comparable  with  an  inexpensive  magnetic  tape  drive 
(30000  characters  per  second,  or  about  10  times  the  speed  of  the  Aipanct).  We  actually  get  about 
double  tills  in  some  favorable  eases.  To  achieve  this  speed  it  was  important  to  design  out 
bottlenecks  such  as  arc  found  in  the  Arpanet,  for  instance  die  control-link  which  is  shared 
between  multiple  connections  and  the  need  to  acknowledge  each  message  before  the  next  message 
can  be  sent  The  protocol  must  be  simple,  for  the  sake  of  reliability  and  to  allow  its  use  by 
modest  computer  systems.  A  full  Chaosnet  Network  Control  Program  is  just  about  half  the  size 
of  an  Arpanet  NCP  on  the  same  machine,  and  the  protocol  allows  low-performance 
implementations  to  omit  some  features.  A  minimal  implementation  exists  for  a  single-chip 
microcomputer. 

3.1  Connections 

The  principal  service  provided  by  Chaosnet  is  a  connection  between  two  user  processes.  This 
is  a  full-duplex  reliable  packet-transmission  channel.  The  network  undertakes  never  to  garble, 
lose,  duplicate,  or  resequence  the  packets;  in  the  event  of  a  serious  error  it  may  break  the 
connection  off  entirely,  informing  both  user  processes.  User  programs  may  ciihcr  deal  in  terms  of 
packets,  or  ignore  packet  boundaries  and  treat  the  connection  as  two  uni  directional  streams  of  8- 
bit  or  16-bit  bytes. 

On  top  of  the  connection  facility  "user"  programs  build  other  facilities,  such  as  file  access, 
interactive  terminal  connections,  and  data  in  other  byte  sizes,  such  as  36  bits.  The  meaning  of 
the  packets  or  bytes  transmitted  through  a  connection  is  defined  by  the  particular  higher-level 
protocol  in  use. 

In  addition  to  reliable  communication,  the  protocol  provides  flow  control,  includes  a  way  by 
which  prospective  communicants  may  get  in  touch  with  each  other  (called  contacting  or 
rendezvous),  and  provides  various  network  maintenance  and  housekeeping  facilities,  ihese  are 
discussed  later. 


3.2  Contact  Names 

When  first  establishing  a  connection,  it  is  necessary  for  the  I  vo  communicating  processes  to 
contact  each  other.  In  addition,  in  the  usual  user/server  situation,  the  server  puiccss  dues  not 
exist  beforehand  and  needs  to  be  created  and  made  to  execute  the  appropriate  piogram. 

We  chose  to  implement  contacting  in  an  asymmetric  way.  (Once  the  connection  lias  been 
established  everything  is  completely  symmcliic.)  One  process  is  designated  the  user,  and  the  other 
is  designated  the  server.  I  lie  server  has  some  contact  name  to  which  ii  listens.  I  he  user  process 
requests  its  local  operating  system  to  connect  il  to  the  sencr.  specifying  the  mi w oik  node  and 
contact  name  ol  the  server.  The  local  operating  system  sends  a  message  (a  Request  for 
(  n/i/u  c  ii,m)  to  the  i' mole  opeiatinj’  system,  which  examines  the  conim  t  name  and  creates  a 
cotuieeiion  to  a  lislemni’  process,  clean-,  a  ikw  seiver  process  and  connects  to  it.  ot  rejects  the 
request. 
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Automatically  discovering  to  which  host  to  connect  in  order  to  obtain  a  particular  service  is  a 
subject  for  higher-level  protocols  and  for  further  research.  It  is  not  dealt  with  by  Chaosnet. 

Once  a  connection  has  been  established,  there  is  no  more  need  for  the  contact  name  and  it  is 
discarded.  Indeed,  often  the  contact  name  is  simply  the  name  of  a  service  (such  as  ’'TELNET") 
and  several  users  should  be  able  to  have  simultaneous  connections  to  separate  instances  of  that 
service,  so  contact  names  must  be  reusable. 

In  the  ease  where  two  existing  processes  that  already  know  about  each  other  want  to  establish 
a  connection,  we  arbitrarily  designate  one  as  the  listener  (server)  and  the  other  as  the  requester 
(user).  The  listener  somehow  generates  a  "unique"  contact  name,  somehow  communicates  it  to 
the  requester,  and  listens  for  it.  TTic  requester  requests  to  connect  to  that  contact  name  and  the 
connection  is  established.  In  the  most  common  ease  of  establishing  a  second  connection  between 
two  prtK'csscs  which  are  already  connected,  the  index  number  (see  below)  of  the  first  connection 
can  serve  as  a  unique  contact  name. 

Contact  names  arc  restricted  to  strings  of  uppercase  letters,  numbers,  and  ASCII  punctuation. 
The  maximum  length  of  a  contact  name  is  limited  only  by  the  packet  size,  although  on  IT'S  hosts 
the  names  of  automatically-started  servers  arc  limited  by  the  file-system  to  six  characters. 

See  page  21  for  complete  details  of  how  to  establish  a  connection. 

3.3  Addresses  and  Indices 

Kach  node  (or  host)  on  the  network  is  identified  by  an  address,  which  is  a  16-bit  number. 
These  addresses  arc  used  in  the  routing  of  packets.  T  here  is  a  table  (the  system  hosts  table, 
SYSB IN ; H0STS2,  in  the  ease  of  IT'S)  which  relates  symbolic  host  names  to  numeric  host 
addresses. 

An  address  consists  of  two  fields.  T  he  most-significant  8  bits  identify  a  subnet,  and  the  least- 
significant  <8  hits  identify  a  host  within  that  subnet.  Both  fields  must  be  non-zero.  A  subnet 
corresponds  to  a  single  transmission  path.  Some  subnets  are  physical  Chaosnet  cables  {ethers), 
while  others  arc  other  media,  for  instance  an  interface  between  a  pdplO  and  a  pdpll.  The 
significance  of  subnets  will  become  clear  when  routing  is  discussed  (see  section  3.7,  page  13). 

When  a  host  is  connected  to  an  ether,  the  host’s  hardware  address  on  that  ether  is  the  same 
as  its  soltw.ue  address,  including  the  subnet  field. 

A  connection  is  specified  by  the  names  of  its  two  ends.  Such  a  name  consists  of  a  16-bit  host 
addiess  and  a  lb-hit  connection  index,  which  is  assigned  h>  that  host,  as  the  name  of  the  entity 
inside  the  host  which  owns  the  connection.  The  only  requirements  placed  In  the  pmiocol  on 
indices  aie  dial  they  he  non  zero  and  that  they  be  unique  within  a  particular  host;  that  is,  a  host 
may  not  avign  the  same  index  number  to  two  dillcmii  loiiucciious  unless  cmnrli  lime  has 
1 1.iJ >’ ed  between  the  closing,  of  the  liisl  connection  .mil  the  opening  of  the  s.soml  connection  that 
confusion  between  the  two  is  unlikely. 


I  •  j  j  i  i .  1 1 1  \  the  |e.p 
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packet  from  the  old  connection  cannot  sit  around  in  the  network  (c.g.  in  buffers  inside  hosts  or 
bridges)  long  enough  to  be  seen  as  belonging  to  the  new  connection. 

It  is  important  to  note  that  packets  arc  not  sent  betv  *»cn  hosts  (physical  computers).  They  are 
sent  between  user  processes;  more  exactly,  between  channels  attached  to  user  processes.  Each 
channel  has  a  32-bit  identification,  which  is  divided  into  subnet,  host,  index,  and  uniquization 
fields.  From  the  point  of  a  view  of  a  user  process  using  the  network,  the  Network  Control 
Program  section  of  his  host’s  operating  system  is  part  of  the  network,  and  the  multiplexing  and 
demultiplexing  it  performs  is  no  different  from  the  routing  performed  by  other  parts  of  the 
network.  It  makes  no  difference  whether  two  communicating  processes  run  in  the  same  host  or  in 
different  hosts. 

Certain  control  packets,  however,  are  sent  between  hosts  rather  than  users.  1'his  is  visible  to 
users  when  opening  a  connection;  a  contact  name  is  only  valid  with  respect  to  a  particular  host. 
This  is  a  compromise  in  the  design  of  Chaosnet,  which  was  made  so  that  an  operational  system 
could  be  built  without  first  solving  the  research  and  engineering  problems  associated  with  making 
a  diverse  set  of  hosts  into  a  uniform,  one-level  name  space. 

3.4  Packet  Numbers 

Inhere  arc  two  kinds  of  packets,  controlled  and  uncontrolled.  Controlled  packets  are  subject  to 
error-control  and  flow-control  protocols,  described  below  (see  section  3.8,  page  16),  which 
guarantee  that  each  controlled  packet  is  delivered  to  its  destination  exactly  once,  that  the 
controlled  packets  belonging  to  a  single  connection  arc  delivered  in  die  same  order  they  were  sent, 
and  that  a  slow  receiver  is  not  overwhelmed  with  packets  from  a  fast  sender.  Uncontrolled 
packets  arc  simply  transmitted;  they  will  usually  but  not  always  arrive  at  their  destination  exactly 
once.  The  protocol  for  using  them  must  take  this  into  account. 

Bach  controlled  packet  is  identified  by  an  unsigned  16-bit  packet  number.  Successive  packets 
arc  identified  by  sequential  numbers,  with  wrap-around  from  all  l’s  to  all  0's.  When  a  connection 
is  first  opened,  each  end  numbers  its  first  controlled  packet  (RFC  or  OFN)  however  it  likes,  and 
that  sets  the  numbering  for  all  following  packets. 

Packet  numbers  should  be  compared  modulo  65536  (2  to  the  16th),  to  ensure  correct  handling 
of  wrap-around  cases.  On  a  pdpll,  use  die  instructions 
CMP  A , B 
BMI  A„is_less 

Do  not  use  the  BLT  or  BLO  instruction.  On  a  pdplO,  use  die  inst.  ctions 
SUB  A  t B 
TRNE  A, 100000 
JHST  A_is_less 

Do  not  use  the  CAMfT  instruction.  On  a  I  asp  machine,  use  the  code 
(II  (till  IFSr  //o  100000  (  A  B)) 

«'A  i  s  I  r  s  s  >  ) 

Do  not  use  the  1  1  SSP  (or  <)  function. 
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3.5  Packets 

A  packet  consists  of  a  header,  which  is  8  16-bit  words,  and  zero  or  more  8-bit  or  16-bit  bytes 

of  accompanying  data.  In  addition  there  are  three  words  put  on  by  the  hardware,  described 

earlier  in  this  paper. 

The  following  arc  the  8  header  words: 

Operation  rfhc  most-significant  8  bits  of  this  word  arc  the  Opcode  of  the  packet,  a 

number  which  tells  what  the  packet  means.  The  128  opcodes  with  high-order 

bit  0  arc  for  the  use  of  the  network  itself.  The  128  opcodes  with  high-order 

bit  1  arc  for  use  by  users.  'Hie  various  opcodes  arc  described  in  chapter  4, 
page  20. 

The  least-significant  8  bits  of  this  word  arc  reserved  for  future  use,  and  must 
be  zero. 

Count  The  most-significant  4  bits  of  this  word  arc  the  forwarding  count,  which  tells 

how  many  times  this  packet  has  been  forwarded  by  bridges.  Its  use  is 
explained  in  the  Routing  section. 

The  least-significant  12  bits  of  this  word  arc  the  data  byte  count,  which  tells 
the  number  of  8-bit  bytes  of  data  in  the  packet.  The  minimum  value  is  0  and 
the  maximum  value  is  488.  Note  that  the  count  is  in  8-bit  bytes  even  if  the 
data  arc  regarded  as  16-bit  bytes. 

Destination  Address 

This  word  contains  the  network  address  of  the  destination  host  to  which  this 
packet  should  be  sent. 

Destination  Index  This  word  contains  the  connection  index  at  the  destination  host  of  the 
connection  to  which  this  packet  belongs,  or  0  if  this  packet  docs  not  belong  to 
any  connection. 

Source  Address  This  word  contains  the  network  address  of  the  source  host  which  originated  this 
packet. 

Source  Index  ITiis  word  contains  die  connection  index  at  the  source  host  of  the  connection 
to  which  this  packet  belongs,  or  0  if  this  packet  docs  not  belong  to  any 
connection. 

racket  Number  If  this  is  a  controlled  packet,  this  word  contains  its  identifying  number. 

Acknowledgement  The  use  of  this  word  is  described  in  section  3.8,  page  16. 
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3,6  Data  Formats 

Data  transmitted  through  Chaosnet  generally  follow  Lisp  Machine  standards.  Hits  and  bytes 
arc  numbered  from  right  to  left,  or  least-significant  to  most-significant.  The  first  8 bit  byte  in  a 
16-bit  word  is  Lite  one  in  the  arithmetically  least-significant  position.  The  first-  16  bit  word  in  a 
32-bit  double-word  is  the  one  in  the  arithmetically  least-significant  position. 

The  character  set  used  is  dictated  by  the  higher-level  protocol  in  u sc.  Telnet  and  Supdtip,  for 
example,  each  specifics  its  own  ASCII-based  character  set.  1'he  "default"  character  set— used  for 
new  protocols  and  for  text  that  appears  in  the  basic  Chaosnet  protocol,  such  as  contact  names— is 
the  Lisp  Machine  character  set  (CHINUAL).  This  is  basically  ASCII,  augmented  with  additional 
printing  characters  and  a  different  set  of  format-effector  (or  "control")  characters. 

Because  the  rules  for  bit  numbering  conflict  with  the  native  byte-ordering  in  pdplOs,  and 
because  it  is  quite  expensive  to  rearrange  the  bytes  using  the  pdplO  instruction  set.  pdplls  which 
act  as  front-ends  for  pdplOs  must  reformat  packets  passing  through  them,  and  pdplOs  interfaced 
directly  to  the  network  must  have  interfaces  capable  of  rearranging  the  bytes.  This  requires  that 
die  network  protocols  explicitly  specify  which  portions  of  each  type  of  packet  are  8-bit  bytes  and 
which  arc  16-bit  bytes.  In  general  the  header  is  16-bit  bytes  and  the  data  field  is  8-bit  bytes,  but 
certain  packet  types  (OPN,  SIS,  RUT,  and  opcodes  300  through  377)  have  16-bit  bytes  in  die 
data  field.  Use  of  32-bit  data  is  rare,  so  no  provision  is  made  for  putting  32-bit  data  into  the 
standard  format  for  pdplOs.  On  our  current  network  pdplOs  are  the  only  hosts  which  require  this 
packet  reformatting  assistance,  because  most  modern  computers  number  their  bits  and  bytes  from 
least-significant  to  most-significant. 

The  effect  of  this  is  diat  user  programs  that  use  the  Chaosnet  always  see  the  data  in  a  packet 
and  its  header  in  the  native  form  of  the  machine  they  arc  running  on,  and  the  necessary 
conversions  are  automatically  applied  by  the  network.  'This  statement  applies  to  die  order  of  bits 
and  bytes  within  a  word,  but  not  to  the  character  set  (when  packets  contain  textual  data)  which  is 
dictated  by  protocols. 

Unlike  some  other  network  protocols,  Chaosnet  docs  not  use  any  software  checksumming. 
Because  of  the  diversity  of  hosts  with  different  architectures  attached  to  the  Chaosnet,  it  is 
impossible  to  devise  a  checksumming  algorithm  which  can  be  executed  compatibly  and  efficiently 
on  all  hosts.  Instead,  Chaosnet  relies  on  error-checking  hardware  in  the  network  interfaces,  and 
assumes  that  other  sources  of  packet  damage  that  checksums  could  detect,  such  as  software  bugs 
in  a  Network  Control  Program,  either  do  not  occur  or  will  produce  symptoms  so  obvious  that 
they  will  be  detected  and  fixed  immediately. 


3.7  Routing 

Routing  consists  of  deciding  how  to  deliver  a  packet  to  the  network  node  specified  by  die 
destination  address  field  of  the  packet.  Having  reached  that  node,  the  packet  tan  trivially  be 
delivered  to  the  destination  user  process  via  the  destination  index.  In  geneul  muting  may  be  a 
multi  step  pmeess  involving  transmission  llnough  several  subnets,  situe  lln  ie  nu\  not  be  a  direct 
hardware  connection  between  the  sou  ice  uni  the  destination.  Note  that  the  loniine  decision  is 
made  separately  for  each  packet,  with  no  /< /<  /cure  jo  dm  </>nicpl  ol ’  tonm <  lions. 
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Any  host  that  is  connected  to  more  than  one  subnet  acts  as  a  bridge  and  forwards  packets 
from  one  subnet  to  another  when  necessary.  There  could  also  he  hardware  bridges  which  are  not 
hosts,  although  we  have  not  yet  designed  any  such  device.  Since  routing  docs  not  depend  on 
connections,  a  bridge  is  a  very  simple  device  (or  program)  which  docs  not  need  much  state.  This 
makes  the  bridge  function  inexpensive  to  piggyback  onto  a  computer  which  is  also  performing 
other  functions,  and  makes  reliable  bridge  software  easy  to  implement. 

The  difference  between  a  bridge  and  a  gateway ,  in  our  terminology,  is  that  a  bridge  forwards 
packets  from  one  sub-Chaosnet  to  another,  without  modifying  the  packets  or  understanding  them 
other  than  to  look  at  the  destination  address  and  increment  the  forwarding  count,  and  does  not 
deal  with  connections  nor  with  flow  control,  while  a  gateway  interconnects  two  networks  with 
differing  protocols  and  must  understand  and  translate  die  information  passing  through  it 
Gateways  may  also  have  to  deal  with  flow  and  error  control  because  they  connect  networks  with 
slow  or  differing  speeds.  Bridges  are  suitable  for  local  networks  while  gateways  arc  suitable  for 
long-distance  networks  and  for  connecting  networks  not  produced  by  the  same  organization. 

To  prevent  routing  loops,  each  packet  contains  a  forwarding-count  field.  Kach  bridge  that 
forwards  the  packet  increments  this  count;  if  the  count  reaches  its  maximum  value  the  packet  is 
discarded.  The  error-control  protocol  will  recover  discarded  packets,  or  decide  diat  no  viable 
connection  can  be  established  between  the  two  hosts. 

The  implementation  of  routing  in  an  operating  system  is  as  follows,  given  a  packet  to  be 
routed,  which  may  have  come  in  from  die  network  or  may  have  been  originated  by  the  local 
host,  first,  check  the  packet’s  destination  address.  If  it  is  this  host,  receive  the  packet. 
Otherwise,  increment  the  forwarding  count  and  discard  the  packet  if  it  has  been  forwarded  too 
many  times.  If  the  destination  is  some  other  host  on  a  subnet  to  which  this  host  is  directly 
connected,  transmit  die  packet  on  that  subnet;  the  destination  host  should  receive  it.  If  the 
destination  is  a  host  on  a  subnet  of  which  this  host  has  no  knowledge,  look  up  the  subnet  in  the 
host’s  routing  table  to  find  the  best  bridge  to  that  subnet,  and  transmit  the  packet  to  diat  bridge. 

Kadi  host  has  a  routing  table,  indexed  by  subnet  number,  which  tells  how  to  get  packets  to 
hosts  on  diat  subnet.  Kach  entry  contains:  (exact  details  may  vary  depending  on  implementation) 

Type  The  type  of  connection  between  the  host  and  this  subnet.  This  can  be  one  of 

Direct ,  Bridge,  or  Fixed  Bridge.  Direct  means  a  physical  connection  such  as  a 
Chaosnet  interface.  Bridge  incans  an  indirect  connection,  via  a  packet-forwarding 
bridge.  Which  bridge  is  best  to  use  is  to  be  discovered  by  this  routing 
mechanism.  I'ixcd  Bridge  is  the  same  except  that  the  automatic  mechanism  is  not 
to  change  which  bridge  is  used.  This  is  useful  to  set  up  explicit  routing  for 
purposes  such  as  network  debugging. 

iifdies\  Identifies  the  (onnection  to  this  subnet  in  a  way  which  depends  on  the  type,  for 

a  due*  t  connection,  this  identities  the  piece  of  hardware  which  implements  the 
connection.  (It  might  be  a  Unibus  address.)  for  a  bridge  or  a  fixed  bridge,  this 
is  the  network  address  of  the  bridge. 

(  f\ t  A  measure  of  the  cost  of  sending  a  packet  (hiough  (his  mute,  lusts  are  used  to 

select  the  best  route  from  among  alternatives  in  a  way  described  below,  for  a 
direct  connection,  tin*  cost  is  10  for  a  dual  inieiface  between  two  computers  (eg. 
b'  lwn  ii  a  pdpIO  ami  its  liohl-mui  pdpll).  II  for  a  (  h.inmU  edict  cable,  i'll  for 
a  slow  medium  stu  b  as  in  jswkhroiums  line,  etc.  l  or  a  btidn.e  or  a  fixed  bridge, 
the  is  spe:  died  b>  the  hi  idee  in  a  III 1 1  p  n  ket  (deM.n bed  below  ). 
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The  routing  table  is  initialized  with  the  number  of  a  more  or  less  arbitrary  existent  host  and  a 
high  cost,  for  each  subnet  to  which  the  host  is  not  directly  connected.  Until  the  correct  bridge  is 
discovered  (which  normally  happens  within  a  minute  of  coming  up),  packets  for  that  subnet  will 
he  bounced  off  of  that  arbitrary  host,  which  probably  knows  the  right  bridge  to  forward  them  to. 

The  cost  for  subnets  accessed  via  bridges  is  increased  by  1  every  4  seconds,  thus  typically 
doubling  after  a  minute.  When  the  cost  reaches  a  ’’high”  value,  it  sticks  there,  preventing 
problems  with  arithmetic  overflow.  The  purpose  of  the  increasing  cost  is  to  discount  the  value  of 
old  information.  Ihc  cost  for  subnets  accessed  via  direct  connections  and  fixed  bridges  docs  not 
increase. 

Every  15  seconds,  a  bridge  advertises  its  presence  by  broadcasting  a  routing  (RUT)  packet  on 
each  subnet  to  which  it  is  directly  connected.  Each  host  on  that  subnet  receives  the  RUT  packet 
and  uses  it  to  update  its  routing  table.  If  die  host’s  routing  table  says  to  access  a  certain  subnet 
via  bridges,  and  the  RUT  packet  says  that  lifts  is  the  best  bridge  to  that  subnet,  the  routing  table 
is  updated  to  say  that  this  bridge  should  be  used. 

Note  that  it  is  important  that  the  rate  at  which  the  costs  increase  with  time  be  slow  enough 
that  it  takes  more  than  twice  the  broadcast  interval  to  increase  the  cost  of  one  hop  to  be  more 
than  the  cost  of  two  hops.  Otherwise  the  muting  algorithm  is  not  well-behaved.  Suppose  subnet 
A  has  two  bridges  («  and  p)  on  it,  and  bridge  a  is  connected  to  subnet  B  but  bridge  p  is  not  (it 
goes  to  some  other  irrelevant  subnet).  Then  if  the  costs  increase  too  fast  and  bridges  «  and  p  do 
not  broadcast  dicir  RUT  packets  exactly  simultaneously,  sometimes  packets  for  subnet  B  may  be 
sent  to  bridge  p  because  its  cost  appears  lower.  Bridge  p  will  then  send  them  to  bridge  «,  where 
they  should  have  gone  directly.  In  more  complicated  situations  packets  can  go  around  in  a  circle 
some  of  the  time. 

The  source  address  of  a  RUT  packet  must  be  the  hardware  address  of  the  bridge  on  the 
particular  subnet  on  which  the  packet  is  broadcast.  The  destination  address  of  a  RUT  packet 
must  be  zero;  RUT  packets  arc  not  forwarded  onto  other  subnets.  Ihc  byte  count  of  a  RUT 
packet  is  a  multiple  of  4  and  the  packet  contains  up  to  122  pairs  of  16-bit  words; 

word  l  The  subnet  number  of  a  subnet  which  this  bridge  can  get  to,  directly  or 

indirectly,  right-adjusted. 

word  2  llic  cost  of  sending  to  that  subnet  via  this  bridge,  lifts  is  the  current  cost  from 

the  bridge’s  routing  table,  plus  the  cost  for  the  subnet  on  which  the  routing 
packet  is  being  broadcast.  Adding  the  subnet  cost  eliminates  loops,  and  prefers 
one-hop  paths  over  two-hop  paths. 

When  a  host  receives  a  RUT  packet,  it  processes  each  2-word  entry  by  comparing  the  cost  for 
that  subnet  against  its  current  cost;  if  it  is  less  or  equal  the  cost  and  the  address  of  the  biidgc 
arc  entered  into  the  routing  table,  provided  that  that  subnet's  routing  table  entry  is  not  of  the 
Direct  or  Fixed  Bridge  type. 

When  there  are  multiple  equivalent  bridges,  the  tra llic  is  spread  among  them  only  by  virtue 
of  their  RUT  packets  being  sent  at  different  times,  so  that  sometimes  one  bride* *  has  ihc  lower 
cost,  and  sometimes  the  other.  II  tins  isn’t  adequate,  hosts  could  have  Iniucr  usiling  tables 
which  icmcmber  mum**  than  one  possible  unite  ami  use  them  aceonling  m  their  iclaiive  i  osls,  Util 
*o  ho  this  has  mn  been  mvev.ny  since  the  nuwoik  irallic  is  net  sn  high  as  to  s.tim  Me  any  one 
bridge. 
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The  design  of  this  routing  scheme  is  predicated  on  the  assumption  that  the  network  geometry 
is  simple,  there  arc  few  multiple  paths,  and  the  length  of  any  path  is  quite  short.  This  makes 
more  sophisticated  schemes  unnecessary. 

An  important  feature  of  this  routing  scheme  is  that  the  size  of  the  table  is  proportional 'to  the 
number  of  subnets,  not  to  the  number  of  hosts.  Thus  it  does  not  take  up  an  inordinate  amount 
of  memory  in  a  small  computer,  and  no  complicated  dynamic  allocation  schemes  arc  required. 

In  the  case  of  a  pdplO  which  accesses  the  Chaosnet  through  a  front-end  pdpll,  we  define  the 
interface  between  the  two  computers  to  be  a  subnet,  and  regard  the  pdpll  as  a  bridge  which 
forwards  packets  between  the  network  and  the  pdplO.  This  gives  the  pdplO  and  the  pdpll 
separate  addresses  so  that  we  can  choose  to  talk  to  either  one,  even  though  they  arc  part  of  the 
same  computer  system.  This  is  occasionally  useful  for  maintenance  purposes.  It  becomes  more 
useful  when  the  front-end  pdpll  has  peripherals  which  arc  to  be  accessed  through  the  Chaosnet, 
since  they  can  simply  look  like  hosts  on  that  pdpll’s  private  subnet. 

In  the  case  of  a  host  which  is  attached  to  more  than  one  subnet,  it  is  undesirable  for  the  host 
to  have  more  than  one  address,  since  this  would  complicate  user  programs  which  use  addresses. 
Instead,  one  of  the  host’s  network  attachments  is  designated  as  primary,  and  that  address  is  used 
as  the  host’s  single  address.  Ihe  other  attachments  arc  regarded  as  bridges  which  can  forward  to 
that  host.  Sometimes,  we  simplify  the  routing  by  inventing  a  new  subnet  which  contains  only  that 
host  and  has  no  physical  realization.  The  host’s  address  is  an  address  on  that  fake  subnet.  All  of 
the  host’s  network  attachments  are  regarded  as  bridges  which  know  how  to  forward  packets  to  that 
subnet. 

The  ITS  host  table  allows  a  host  to  have  multiple  addresses  on  multiple  networks,  but  when 
you  ask  for  the  address  of  a  certain  host  on  a  certain  network  you  only  get  back  the  primary 
address.  All  packets  coming  from  that  host  have  that  as  their  source  address. 

3.8  Flow  and  Error  Control 

The  Network  Control  Programs  (NCPs)  conspire  to  ensure  that  data  packets  arc  sent  from 
user  to  user  with  no  garbling,  duplications,  omissions,  or  changes  of  order.  Secondarily,  the 
NCPs  attempt  to  achieve  a  maximum  rate  of  flow  of  data,  and  a  minimum  of  overhead  and 
retransmission. 

The  fundamental  basis  of  flow-control  and  error-control  in  Chaosnet  is  retransmission.  Packets 
which  are  damaged  in  tiansmission,  which  won’t  fit  in  hollers,  which  are  duplicated  or  out-of- 
scqucnce,  or  which  otherwise  arc  embarrassing  are  simply  discarded.  Packets  are  periodically 
retransmitted  until  an  indication  that  they  have  been  successfully  receiscd  is  return'd.  This 
retransmission  is  cinMo-end;  any  intermediate  bridges  do  not  participate  in  How-control  and  error- 
control,  and  hence  arc  free  to  discard  any  packets  they  wish. 

There  arc  actually  two  kinds  of  packets,  controlled  and  uncontrolled.  Controlled  packets  arc 
retransmitted  and  delivered  reliably;  most  packets,  including  all  packets  used  by  the  user  (except 
for  I  INC  packets),  are  of  this  type.  Uncontrolled  packets  are  not  retransmitted;  these  are  used 
loi  unt.iiii  lower '  level  functions  ol  the  protocol  such  as  the  implementation  of  (low  and  error 
control.  I  lie  usage  of  these  packets  is  designed  so  that  they  need  not  he  il'  livi-ied  rclnhly. 
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Retransmission  of  a  packet  continues  until  stopped  by  a  signal  from  the  receiver  to  [jic  sender 
called  a  receipt .  A  receipt  contains  a  packet  number ,  and  indicates  that  all  controlled  packets  with 
a  packet  number  less  than  or  equal  (modulo  65536)  to  that  number  have  been  successfully 
received,  and  therefore  need  not  be  retransmitted  any  more.  A  receipt  docs  not  indicate  that 
these  packets  have  been  processed  by  the  destination  user  process;  it  simply  indicates  that  they 
have  successfully  arrived  in  the  destination  host,  and  are  guaranteed  to  be  there  when  the  user 
process  asks  for  them. 

There  is  another  signal  from  the  receiver  to  the  sender,  called  an  acknowledgement.  An 
acknowledgement  also  contains  a  packet  number,  and  indicates  that  all  controlled  packets  with  a 
packet  number  less  than  or  equal  (modulo  65536)  to  that  number  have  been  read  by  the 
destination  user  process.  This  is  used  to  implement  flow-control.  Note  that  acknowledgement  of  a 
packet  implies  receipt  of  that  packet.  In  fact,  if  the  receiving  process  does  not  fall  behind, 

explicit  receipts  need  not  be  sent,  because  die  receiving  host  will  not  have  to  buffer  any  packets, 

but  will  acknowledge  them  as  soon  as  they  arrive. 

The  purpose  of  flow-control  is  to  match  the  speeds  of  the  sending  and  receiving  processes. 
The  extremes  to  be  avoided  are,  on  the  one  hand,  too  small  a  ’’buffer  size"  causing  the  data 
transmission  rate  to  be  slower  than  it  could  be,  and  on  the  other  hand,  large  numbers  of  packets 
piling  up  in  the  network  because  the  sender  is  sending  faster  than  the  receiver  is  receiving.  It  is 
also  necessary  to  be  aware  that  receipts  and  acknowledgements  must  be  transmitted  through  the 
network,  and  hence  have  an  associated  cost. 

Chaosnet  flow-control  operates  by  controlling  the  number  of  packets  "in  the  network".  ITicse 
are  packets  which  have  been  emitted  by  the  sending  user  process,  but  have  not  been 
acknowledged.  We  define  a  window  into  the  set  of  packet  numbers.  The  beginning  of  this 

window  is  the  first  packet  number  which  has  not  been  acknowledged,  and  the  width  of  the 

window  is  a  fixed  number  established  when  the  connection  is  opened.  The  sending  process  is 
only  allowed  to  emit  packets  whose  packet  numbers  lie  within  the  window.  Once  it  has  emitted 
all  of  the  packets  in  the  window,  the  window  is  said  to  be  full.  Thus,  the  size  of  the  window  is 
the  "buffer  size"  for  the  connection,  and  is  the  maximum  number  of  packets  that  may  need  to  be 
buffered  inside  an  NCR  (sending  or  receiving).  Acknowledgements  move  the  window,  making  it 
not  full,  and  allowing  the  sending  process  to  emit  additional  packets. 

We  do  not  receipt  and  acknowledge  every  single  controlled  packet  that  is  transmitted  through 
a  connection,  since  that  would  double  or  triple  the  number  of  packets  sent  through  the  network 
to  move  a  given  amount  of  data.  Instead  we  batch  the  receipts  and  acknowledgements.  Hut  if 
acknowledgements  are  not  sent  sufficiently  often,  the  data  will  not  flow  smoothly,  because  the 
window  will  often  appear  full  to  the  sender  when  it  is  not.  If  receipts  are  not  sent  sufficiently 
often,  there  will  be  unnecessary  retransmissions. 

Whenever  a  packet  is  sent  through  a  connection,  an  acknowledgement  for  the  reverse 
direction  of  that  connection  is  "piggy  bai  ked"  onto  it,  using  the  Acknowledgement  field  in  the 
packet  header.  I  or  interactive  applications,  where  there  is  much  irallic  in  both  dilations,  this 
provides  all  the  necessary  acknowledgement  and  receipting  with  no  need  to  send  any  extra  packets 
through  the  network. 

When  this  does  not  mi  Hire,  SI'S  (Mains)  packets  are  generated  to  canv  ivcipts  and 
acknowledgements.  SIS  packets  ate  tin-,  .mimllcd,  since  they  ate  pat  l  of  the  nn,  li.iiiKiu  that 
implements  controlled  packets.  If  an  MS  pukcl  is  duplicated,  it  does  no  harm.  It  an  STS 
packet  is  lost.  mechanisms  exist  which  will  cause  a  replacement  m  be  ccncuted  later.  An  SIS 
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packet  carries  separate  receipt  and  acknowledgement  packet  numbers. 

When  a  user  process  reads  a  packet  from  the  network,  if  the  number  of  packets  which  should 
have  been  acknowledged  but  have  not  been  is  more  than  1/3  the  window  size,  an  STS  is 
generated  to  acknowledge  them.  'Hius  the  preferred  batch  size  for  acknowledgement  is  1/3  the 
window  size.  The  advantage  of  this  size  is  that  if  one  STS  is  lost,  another  will  be  generated 
before  the  window  fills  up  (at  the  2/3  point). 

When  a  packet  is  received  with  the  same  packet  number  as  one  which  has  already  been 
successfully  received,  this  is  evidence  of  unnecessary  retransmission,  and  an  SI'S  is  generated  to 
carry  a  receipt  back  to  the  sender.  If  this  STS  is  lost,  the  next  retransmission  will  stimulate 
another  one.  I'hus  receipts  arc  normally  implied  by  acknowledgements,  and  only  sent  separately 
when  there  is  evidence  of  unnecessary  retransmission. 

Retransmission  consists  of  sending  all  unreceipted  controlled  packets,  except  those  that  were 
last  sent  very  recently  (within  1/30‘th  of  a  second  in  ITS.)  Retransmission  occurs  every  1/2 
second.  This  interval  is  somewhat  arbitrary,  but  should  be  close  to  the  response  time  of  the 
systems  involved.  Retransmission  also  occurs  in  response  to  an  STS  packet,  so  that  a  receiver 
may  cause  a  faster  retranmission  rate  than  twice  a  second  if  it  so  desires.  1Tii$  should  never  cause 
useless  retransmission,  since  SI'S  carries  a  receipt,  and  very-rcccntly-transmittcd  packets,  which 
might  still  be  in  transit  through  the  network,  are  not  retransmitted. 

Another  operation  is  probing ,  which  consists  of  sending  a  SNS  packet,  in  the  hope  of 
eliciting  either  an  STS  or  a  LOS,  depending  on  whether  the  other  side  believes  the  connection 
exists.  Probing  is  used  periodically  as  a  way  of  testing  that  the  connection  is  still  open,  and  also 
serves  as  a  way  to  get  STS  packets  retransmitted  as  a  hedge  against  the  loss  of  an 
acknowledgement,  which  could  otherwise  stymie  the  connection.  SNS  packets  are  uncontrolled. 

We  probe  every  five  seconds  on  connections  which  have  unacknowledged  packets  outstanding 
(a  non-empty  window)  and  on  connections  which  have  not  received  any  packets  (neither  data  nor 
control)  for  one  minute.  If  a  connection  receives  no  packets  for  1  1/2  minutes,  this  means  that  at 
least  5  probes  have  been  ignored,  and  the  connection  is  declared  to  be  broken;  either  the  remote 

host  is  down  or  there  is  no  viable  path  through  die  network  between  the  two  hosts. 

The  receiver  can  generate  "spontaneous"  STS’s,  to  stimulate  retransmission  and  keep  tilings 
moving  on  fast  devices  with  insufficient  buficring  for  1/2  second  worth  of  packets.  This  provides 
a  way  for  the  receiver  to  speed  up  die  retransmission  timeout  in  the  sender,  and  to  make  sure 
that  acknowledges  arc  happening  often  enough. 

Note  that  die  network  still  functions  if  either  or  both  parties  to  a  connection  ignore  the 
window.  I  he  window  is  simply  an  improver  of  efficiency.  Receipts  have  the  same  property.  This 
allows  very  small  implementations  to  be  compatible  with  the  same  protocol,  which  is  useful  for 
applications  such  as  bootstrapping  through  the  network. 

It  would  be  possible  to  have  dynamic  adjustment  of  the  window  size  in  response  to  observed 
behavior.  I  he  SIS  packet  includes  the  window  si/e  so  that  changes  to  it  can  be  communicated. 
However,  tins  has  not  been  found  necc^ary  in  practice.  Inch  higher  level  protocol  has  a  standard 
pie  delci mm<  d  window  st/e.  which  it  establishes  when  it  fust  opens  a  connection,  and  this  seems 

to  be  dose  enough  to  optimum  that  caiclu!  dvnamn  adjustment  of  n  wouldn't  make  a  big 

dilleience. 


I  rd . ;M<  )<  ),V  AMIll  K  107 


IS  1UN  .SI 


Chaosnet 


19 


l;low  and  Krror  Control 


This  scheme  for  flow-control  and  error-control  is  based  on  several  assumptions.  It  is  assumed 
that  the  underlying  transmission  media  have  their  own  checking,  so  that  they  discard  all  damaged 
packets,  making  packet  checksums  unnecessary  at  the  protocol  level.  The  transit  time  through  the 
network  is  assumed  to  be  fast,  so  that  a  fairly-small  retransmission  interval  is  practical,  and 
negative  acknowledgements  are  not  necessary.  The  error  rate  is  assumed  to  be  low  so  that  overall 
efficiency  is  not  affected  by  the  simple-minded  error  recovery  scheme  of  simply  retransmitting  all 
outstanding  packets.  It  is  assumed  that  no  reformatting  of  packets  occurs  inside  the  network,  so 
that  flow-control  and  error-control  can  operate  on  a  packet  basis  rather  than  a  byte  basis. 
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4.  Software  Protocol-Details 

In  the  following  sections,  each  of  the  packet  Opcodes  and  the  use  of  that  packet  type  in  the 
protocol  is  described.  Opcodes  arc  given  as  an  octal  number,  a  thrccdcttcr  code,  and  a  name. 

Unless  otherwise  specified,  the  use  of  the  fields  in  the  packet  header  is  as  follows.  The 
source  and  destination  address  and  index  denote  the  two  ends  of  the  connection;  when  an  end 
docs  not  exist,  as  during  initial  connection  establishment,  that  index  is  zero.  The  opcode,  byte 
count,  and  forwarding  count  fields  have  no  variations.  The  packet  number  field  contains 
sequential  numbers  in  controlled  packets;  in  uncontrolled  packets  it  contains  the  same  number  as 
the  next  controlled  packet  will  contain,  llie  acknowledgement  field  contains  the  packet  number  of 
the  last  packet  seen  by  the  user. 

41  Connection  Establishment 

The  following  packet  types  arc  associated  with  creating  and  destroying  connections.  First  the 
packets  are  described  and  then  the  details  of  the  various  connection-establishment  protocols  are 
given. 

1  RFC  Request  for  connection 

Ail  connections  are  initiated  by  the  transmission  of  an  RFC  from  the  user  to  the  server.  rFhe 
data  field  of  the  packet  contains  the  contact  name.  The  contact  name  can  be  followed  by 
arbitrary  arguments  to  the  server,  delimited  by  a  space  character.  The  destination  index  field  of 
an  RFC  contains  0  since  the  destination  index  is  not  known  yet. 

RFC  is  a  controlled  packet;,  it  is  retransmitted  until  some  sort  of  response  is  received, 
because  RFC’s  arc  not  sent  over  normal,  error-controlled  connections,  a  special  way  of  detecting 
and  discarding  duplicates  is  required.  When  an  NCP  receives  an  RFC  packet,  it  checks  all 
pending  RFC’s  and  all  connections  which  arc  in  the  Open  or  RFC-received  state  (see  section  4.6, 
page  25),  to  see  if  the  source  address  and  index  match;  if  so,  the  RFC  is  a  duplicate  and  is 
discarded. 

12  LSN  Listen 

A  server  process  informs  the  local  NCP  of  the  contact  name  to  which  it  is  listening  by 
sending  a  LSN  packet,  with  the  contact  name  in  the  data  field.  This  packet  is  never  transmitted 
anywhere  through  the  network.  It  simply  serves  as  a  convenient  buffer  to  hold  the  server’s  contact 
name.  When  an  RFC  and  a  LSN  containing  the  same  contact  name  meet,  the  LSN  is  discarded 
and  die  RFC1  is  given  to  the  server,  putting  its  connection  into  the  RFC-received  slate  (see  section 
4.6,  page  25).  T  he  server  reads  the  RFC  and  decides  whether  or  not  to  open  the  connection. 


2  OPN  Open  connection 

OPN  is  die  usual  positive  response  to  RPC.  The  source  index  field  convex s  the  server's  index 
number  to  the  user;  the  user’s  index  number  was  nmvcml  in  the  RFC.  I  he  data  field  of  OPN 
is  the  same  as  that  of  S  I  S  (see  below);  it  serve*  in«iinl>  to  «.onve>  the  server’s  window  si/e  to  the 
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user.  The  Acknowledgement  field  of  the  OPN  acknowledges  the  RFC  so  that  it  will  no  longer  be 
retransmitted. 

OPN  is  a  controlled  packet;  it  is  retransmitted  until  it  is  acknowledged.  Duplicate  OPN 
packets  arc  detected  in  a  special  way;  if  an  OPN  is  received  for  a  connection  which  is  not  in  the 
RFC-sent  suite  (sec  section  4.6,  page  25),  it  is  simply  discarded  and  an  SI'S  is  sent.  This  can 
happen  if  the  connection  is  opened  while  a  retransmitted  OPN  packet  is  in  transit  through  the 

network,  or  if  the  SIS  which  acknowledges  an  OPN  is  lost  in  the  network. 

3  CLS  Close  connection 

CCS  is  the  negative  response  to  RPC.  It  indicates  that  no  server  was  listening  to  the  contact 
name,  and  one  couldn’t  be  created,  or  for  some  reason  the  server  didn’t  feel  like  accepting  this 
request  for  a  connection,  or  die  destination  NCP  was  unable  to  complete  die  connection  (c.g. 
connection  table  full.) 

CLS  is  also  used  to  close  a  connection  after  it  has  been  open  for  a  while.  Any  data  packets 
in  transit  may  be  lost.  Protocols  which  require  a  reliable  end-of-data  indication  should  use  the 

mechanism  for  that  (see  section  4.4,  page  24)  before  sending  CLS. 

The  dam  field  of  a  CLS  contains  a  character-string  explanation  of  the  reason  for  closing, 
intended  to  be  returned  to  a  user  as  an  error  message. 

CLS  is  an  uncontrolled  packet,  so  that  the  program  which  sends  it  may  go  away  immediately 
afterwards,  leaving  nothing  to  retransmit  die  CLS.  Since  there  is  no  error  recovery  or 

retransmission  mechanism  for  CLS,  the  use  of  CLS  is  necessarily  optional;  a  process  could  simply 
stop  responding  to  its  connection.  However,  it  is  desirable  to  send  a  CI  S  when  possible  to 
provide  an  error  message  for  the  user. 

4  FWD  I  'orward  a  request  for  connection 

This  is  a  response  to  RFC  which  indicates  dial  the  desired  service  is  not  available  from  the 

process  contacted,  but  may  be  available  at  a  possihly-diffcrcnt  contact  name  at  a  possibly -different 

host.  The  data  field  contains  die  new  contact  name  and  the  Acknowledgement 
field — exceptionally — contains  the  new  host  number.  The  issuer  of  the  RFC  should  issue  another 
RFC  to  that  address.  FWD  is  an  uncontrolled  packet;  if  it  is  lost  in  the  network,  the 

retransmission  of  the  RI;C  will  presumably  stimulate  an  identical  FWD, 

5  ANS  Answer  to  a  simple  transaction 

This  is  another  kind  of  response  to  RI  C.  The  data  field  contains  the  entirety  of  the  response, 
and  no  connection  is  established.  ANS  is  an  uncontrolled  packet;  if  it  is  lost  in  the  network,  die 
retransmission  of  the  RFC  vviJJ  presumuMv  sfimulah1  an  identical  ANS. 

I  here  are  several  connection  initiation  pmtocols  implemented  with  these  packet  types. 

When  an  RFC  aniws  at  a  host,  (h  N(  1*  finds  a  usei  priM.co  that  is  liMonine  for  lias  RFC's 
contact  name,  nr  creates  a  ^ or\ or  pm<v  \  pmvidc  the  desired  semee,  or  tv-po.ids  to  the  RFC 
itself  if  it  knows  how  to  provide  the  leqne  a  d  “,-ivice.  ot  r« ‘fuses  the  lequcsl  for  connection.  I  he 
process  that  serves  the  RFC.  chooses  which  ■  i  nnet  non  'initiation  protocol  to  follow,  this  process  is 
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given  the  RFC  as  data,  so  that  it  can  look  at  the  contact  name  and  any  arguments  that  may  be 
present 

A  stream  connection  is  initiated  by  an  RFC,  transmitted  from  user  to  server.  The  server 
returns  an  OPN  to  the  user,  which  responds  with  an  STS.  These  three  packets  convey  the  'Source 
and  destination  addresses,  indices,  initial  packet  numbers,  and  window  si/.es  between  the  two 
NCP’s.  In  addition  a  character-string  argument  can  be  conveyed  from  the  user  to  the  server  in 
the  RFC. 

The  OPN  serves  to  acknowledge  the  RFC  and  extinguish  its  retransmission.  It  also  carries  the 
server’s  index,  initial  packet  number,  and  window  size.  The  STS  serves  to  acknowledge  the  OPN 
and  extinguish  its  retransmission.  It  also  carries  the  user’s  window  size;  the  user’s  index  and 
initial  packet  number  were  carried  by  the  RFC.  Retransmission  of  the  RFC  and  the  OPN 
provides  reliability  in  the  face  of  lost  packets.  If  the  RFC  is  lost,  it  will  be  retransmitted.  If  the 
STS  is  lost,  the  OPN  will  be  retransmitted.  If  the  OPN  is  lost,  the  RFC  will  be  retransmitted 
superfluously  and  the  OPN  will  be  retransmitted  since  no  STS  will  be  sent. 

The  exchange  of  an  OPN  and  an  SI'S  tells  each  side  of  the  connection  that  the  other  side 
believes  the  connection  is  open;  once  this  has  happened  data  may  begin  to  flow  through  the 
connection.  The  user  process  may  begin  transmitting  data  when  it  sees  the  OPN.  The  server 
process  may  begin  transmitting  data  when  it  sees  the  SI'S.  These  rules  ensure  that  data  packets 
cannot  arrive  at  a  receiver  before  it  knows  and  agrees  that  the  connection  is  open.  If  data  packets 
did  arrive  before  then,  the  receiver  would  reject  them  with  a  LOS  (see  below),  believing  them  to 
be  a  violation  of  protocol,  and  this  would  destroy  the  connection  before  it  was  ever  ftd/y 
established. 

Once  data  packets  begin  to  flow,  they  are  subject  to  the  flow  and  error  control  protocol 
described  in  section  3.8,  page  16.  Thus  a  stream  connection  provides  the  desired  reliable, 
bidirectional  data  stream. 

A  refusal  is  initiated  by  an  RFC  in  the  same  way,  but  the  server  returns  C1.S  rather  than 
OPN.  The  data  field  of  the  CLS  contains  die  reason  for  refusal  to  connect. 

A  forwarded  connection  is  initiated  by  an  RI;C  in  the  same  way,  but  the  server  returns  a 
l  Wl),  telling  die  user  another  place  to  look  for  the  desired  service. 

A  simple  transaction  is  initiated  by  an  RFC  from  user  to  server,  and  completed  by  an  ANS 
from  server  to  user.  Since  a  full  connection  is  not  established  and  the  reliable-transmission 
i ik\  h<m ism  of  connections  is  not  used,  the  user  process  cannot  be  sure  how  many  copies  of  the 
Kit  the  server  saw,  and  the  server  process  cannot  be  sine  that  its  answer  got  hack  to  the  user. 
Ihi\  means  lli.it  simple  transactions  >hould  not  be  used  for  applications  where  it  is  important  to 
know  whether  the  transaction  was  real  I  >  completed,  nor  for  applications  in  which  repealing  the 
same  qnciv  might  produce  a  different  answer.  Simple  transactions  are  a  simple  cdicient 
nuchuntsm  for  applications  such  as  extracting  a  small  piece  of  information  (e.g.  ihc  time  of  day) 
fioin  a  central  data  base. 
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4.2  Status 


Status 


STS  is  an  uncontrolled  packet  which  is  used  to  convey  status  information  between  NCPs.  'lTie 
Acknowledgement  field  in  the  packet  header  contains  an  acknowledgement,  that  is,  the  packet 
number  of  the  last  packet  given  to  the  receiving  user  process.  The  first  16-bit  byte  in  the  data 
field  contains  a  receipt,  that  is,  a  packet  number  such  that  all  controlled  packets  up  to  and 
including  dial  one  have  been  successfully  received  by  the  NCP.  The  second  16-bit  byte  in  the 
data  field  contains  the  window  size  for  packets  sent  in  die  opposite  direction  (to  the  end  of  the 
connection  which  sent  die  SI'S).  The  byte  count  is  presendy  always  4.  This  will  change  if  the 
protocol  is  revised  to  add  additional  items  to  the  SI’S  packet. 

6  SNS  Sense  status 

SNS  is  an  uncontrolled  packet  whose  sole  purpose  is  to  cause  the  other  end  of  the  connection 
to  send  back  an  STS.  'This  is  used  by  die  probing  mechanism  described  above  (sec  page  18). 

11  LOS  Lossage 

LOS  is  an  uncontrolled  packet  which  is  used  by  one  NCP  to  inform  another  of  an  error.  The 
data  field  contains  a  character-string  explanation  of  die  problem.  The  source  and  destination 
addresses  and  indices  arc  simply  the  destination  and  source  addresses  and  indices,  respectively,  of 
the  erroneous  packet,  and  do  not  necessarily  correspond  to  a  connection.  When  an  NCP  receives 
a  LOS  whose  destination  corresponds  to  an  existent  connection  and  whose  source  corresponds  to 
die  supposed  other  end  of  that  connection,  it  breaks  die  connection  and  makes  the  data  field  of 
the  I. OS  available  to.  the  user  as  an  error  message.  Other  LOS’s,  that  don’t  correspond  to 
connccdons,  are  simply  ignored. 

LOS  is  sent  in  response  to  situations  such  as:  arrival  of  a  data  packet  or  an  SI'S  for  a 
connection  that  docs  not  exist  or  is  not  open,  arrival  of  a  packet  from  die  wrong  source  for  its 
destination,  arrival  of  a  packet  containing  an  undefined  opcode  or  too  large  a  byte  count,  etc. 

I. OS’s  are  given  to  the  user  process  so  that  it  may  read  the  error  message. 

No  LOS  is  given  in  response  to  an  OPN  to  a  connection  not  in  the  RLC-Scnt  state,  nor  in 
response  to  a  SNS  to  a  connection  not  in  the  Open  state,  nor  in  response  to  a  1  OS  to  a  non¬ 
existent  or  broken  connection.  These  rules  arc  important  to  nuue  die  protocols  work  without 
timing  errors.  An  OPN  or  a  SNS  to  a  non-existent  connection  elicits  a  LOS. 
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4.3  Data 

200-277  DAT  8-bit  Data 

Opcodes  200  through  277  (octal)  arc  controlled  packets  with  user  data  in  8-bit  bytes  in  the 
data  field.  The  NCP  treats  all  64  of  these  opcodes  identically;  some  higher-level  protocols  use  the 
opcodes  for  their  own  purposes,  lhe  standard  default  opcode  is  200. 

300-377  DAT  16-bit  Data 

Opcodes  300  through  377  (octal)  arc  controlled  packets  with  user  data  in  16-bit  bytes  in  the 
data  field.  The  NCF  treats  all  64  of  these  opcodes  identically;  some  higher-level  protocols  use  the 
opcodes  for  their  own  purposes.  The  standard  default  opcode  for  16-bit  data  is  300. 

16  UNO  Uncontrolled  Data 

This  is  an  uncontrolled  packet  with  user  data  in  8-bit  bytes  in  the  data  field.  It  exists  so  that 

user-level  programs  may  bypass  the  flow-control  mechanism  of  Chaosnet  protocol.  Note  that  the 
NCI*  is  free  to  discard  these  packets  at  any  time,  since  they  arc  uncontrolled.  Since  UNC’s  are 
not  subject  to  flow  control,  discarding  may  be  necessary  to  avoid  running  out  of  buffers.  A 
connection  may  not  have  more  input  packets  queued  awaiting  the  attention  of  the  user  program 
than  the  window  size  of  the  connection,  except  that  you  arc  always  allowed  to  have  one  UNC 
packet  queued.  If  no  normal  data  packets  are  in  use,  up  to  one  more  UNC  packet  than  the 
window  size  may  be  queued. 

UNC  packets  arc  also  used  by  the  standard  protocol  for  encapsulating  packets  of  foreign 
protocols  for  transmission  through  Chaosnet  (see  chapter  6,  page  32). 

4.4  End-of-Data 

14  EOF  HndofFilc 

HOI*  is  a  controlled  packet  which  serves  as  a  "logical  end  of  data"  mark  in  the  packet  stream. 
When  the  user  program  is  ignoring  packets  and  treating  a  Chaosnet  connection  as  a  conventional 
byte-stream  I/O  device,  the  NCP  uses  the  HOF  packet  to  convey  tile  notion  of  conventional  end- 
nf-lilc  from  one  end  of  the  connection  to  the  other.  When  the  user  program  is  working  at  the 
packet  level,  it  may  transmit  and  receive  HOF’S. 

HOI*  packets  are  used  in  the  following  protocol  which  is  the  recommended  way  to  reliably 
determine  that  all  data  have  been  transferred  before  dosing  a  connection  (in  applications  where 
that  is  an  impoitant  consideration). 

lhe  important  issue  is  that  neither  side  may  send  a  CI  S  until  both  sides  are  sure  that  all  the 
diti  hoc  been  UaiiMnitlcd.  After  sending  all  the  data  it  is  going  to  send,  including  an  HOF 
p  k  ket  to  mark  (lie  end,  the  sending  pro*  ess  waits  lor  all  packets  to  lx*  acknowledged.  This 
*  i.  1 1 iv.  ih.it  the  iviei\er  has  seen  nil  the  data  and  knows  that  no  mine  data  me  In  initio,  lhe 
i-din  lliii  i  In  «'s  the  uiiiimiiiiit.  When  (it.  i-M*i\iiig  pnnw,  secs  an  I  the  it  knows 

ih  a  ill  te  "r  no  iiidt  data  |i  dneN  tint  *\  »i*  ihr  M-niio'ieii  until  it  se*  tile  \rrnlt  1  dire  il,  nl 
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until  a  brief  timeout  elapses.  The  timeout  is  to  provide  for  the  case  where  the  sender's  CLS  gets 
lost  in  the  network  (CLS  cannot  be  retransmitted).  The  timeout  is  long  enough  (a  few  seconds) 
to  make  it  unlikely  that  the  sender  will  not  have  seen  die  acknowledgement  of  the  LOb  by  the 
time  the  timeout  is  over. 

To  use  this  protocol  in  a  bidirectional  fashion,  where  both  parties  to  die  connection  are 
sending  data  simultaneously,  it  is  necessary  to  use  an  asymmetrical  protocol.  Arbitrarily  call  one 
party  the  user  and  the  other  die  server.  The  pro^jcol  is  that  after  sending  all  its  data,  each  party 
sends  an  HOF  and  waits  for  it  to  be  acknowledged.  The  server,  having  seen  its  HOF 
acknowledged,  sends  a  second  EOF.  The  user,  having  seen  its  HOF  acknowledged,  looks  for  a 
second  HOF  and  (hen  sends  a  CLS  and  goes  away.  The  server  goes  away  when  it  secs  the  user’s 
CLS,  or  after  a  brief  timeout  has  elapsed.  ITns  asymmetrical  protocol  guarantees  that  each  side 
gets  a  chance  to  know  that  both  sides  agree  that  all  the  data  have  been  transferred.  The  first 
CLS  will  only  be  sent  after  both  sides  have  waited  for  their  (first)  HOF  to  be  acknowledged. 

4.5  Low-level 

13  MNT  Maintenance 

MNT  is  a  special  packet  type  reserved  for  the  use  of  network  maintenance  programs.  Normal 
NCPs  should  simply  discard  any  MNT  packets  they  receive.  MNT  packets  arc  an  escape 
mechanism  to  allow  special  programs  to  send  packets  that  arc  guaranteed  not  to  get  confused  with 
normal  packets.  MNT  packets  are  forwarded  by  bridges  although  usually  one  would  not  be 
depending  on  this. 

10  RUT  Routing  Information 

RUT  is  a  special  packet  type  broadcast  by  bridges  to  inform  other  nodes  of  the  bridge’s 
ability  to  forward  packets  between  subnets.  The  source  address  is  the  network  address  of  the 
bridge  on  die  subnet  on  which  the  RUT  was  broadcast.  The  destination  address  is  zero.  The 
byte  count  is  a  multiple  of  4,  and  the  data  field  contains  a  series  of  pairs  of  16-bit  bytes:  a 
subnet  number  and  the  "cost"  of  getting  to  dial  subnet  via  this  bridge.  T  he  packet  number  and 
acknowledgement  fields  are  not  used  and  should  contain  zero.  See  section  3.7,  page  13  for  the 
details. 

4.6  Connection  States 

A  user  process  gets  to  Chaosnet  by  means  of  a  capability  or  channel  (dependent  ot i  the  host 
operating  system)  which  corresponds  to  one  end  of  a  connection.  Associated  with  this  channel  arc 
a  number  of  bullets  containing  controlled  packets  output  by  the  user  and  not  yet  receipted,  and 
data  packets  received  from  die  network  but  not  yet  read  by  die  user;  some  of  these  incoming 
packets  arc  in-order  by  packet  number  and  hence  may  be  read  by  the  user,  while  others  are  out 
of  order  and  cannot  be  read  until  packets  cailier  in  the  stream  have  been  leeched.  Ceitain 
control  packets  are  also  given  to  the  user  as  if  they  were  data  packets.  These  ate  RFC’,  A  NS, 
CT  S,  LOS.  HOF,  and  UN<_\  HOF  is  iln*  only  type  that  ran  ever  he  oul-of-oider. 
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Also  associated  with  the  channel  is  a  state,  usually  called  the  connection  state.  Full 
understanding  of  these  states  depends  on  the  descriptions  of  packet-types  above.  The  state  can  be 
one  of: 


Open  The  connection  exists  and  data  may  be  transferred. 

Closed  The  channel  does  not  have  an  associated  connection.  Either  it  never  had  one  or  it 

has  received  or  transmitted  a  CLS  packet,  which  destroyed  the  connection. 


Listening  The  channel  docs  not  have  an  associated  connection,  but  it  has  a  contact  name 
(usually  contained  in  a  LSN  packet)  for  which  it  is  listening. 

RFC  Received  A  Listening  channel  enters  this  state  when  an  RFC  arrives.  It  can  become  Open 
if  the  user  process  accepts  the  request. 


RPC  Sent  The  user  has  transmitted  an  RFC.  The  state  will  change  to  Open  or  Closed  when 
the  reply  to  the  RFC  comes  back. 


Lost 


The  connection  has  been  broken  by  receiving  a  LOS  packet. 


Incomplete  Transmission 

The  connection  has  been  broken  because  the  other  end  has  ceased  to  transmit  and 
to  respond  to  SNS.  Hither  the  network  or  the  foreign  host  is  down.  (This  can 
also  happen  if  the  local  host  goes  down  for  a  while  and  then  is  revived,  if  its 
clock  runs  in  the  meantime.) 


Foreign  The  channel  is  talking  some  foreign  protocol,  whose  packets  arc  encapsulated  in 

UNC  packets.  As  far  as  Chaosnet  is  concerned  there  is  no  connection.  See 
chapter  6,  page  32  for  the  details. 
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5.  Higher-Level  Protocols 

This  chapter  briefly  documents  some  of  the  higher-level  protocols  of  the  most  general  interest. 
There  are  quite  a  few  other  protocols  which  are  too  specialized  to  mention  here.  All  protocols 
other  than  the  STATUS  protocol  are  optional  and  are  only  implemented  by  those  hosts  that  need 
them.  All  hosts  arc  required  to  implement  the  STATUS  protocol  since  it  is  used  for  network 
maintenance. 

5.1  Status 

All  network  nodes,  even  bridges,  arc  required  to  answer  RFC’s  with  contact  name  STATUS, 
returning  an  A  NS  packet  in  a  simple  transaction.  This  protocol  is  primarily  used  for  network 
maintenance.  The  answer  to  a  STATUS  request  should  be  generated  by  the  Network  Control 
Program,  rather  than  by  starting  up  a  server  process,  in  order  to  provide  rapid  response. 

llic  STATUS  protocol  is  used  to  determine  whether  a  host  is  up,  to  determine  whether  an 
operable  path  through  the  network  exists  between  two  hosts,  to  monitor  network  error  statistics, 
and  to  debug  new  Network  Control  Programs  and  new  Chaosnet  hardware,  llie  hostat  function 
on  the  Lisp  machine,  and  the  Hostat  command  of  die  CHATST  program  on  ITS  arc  user  ends 
for  this  protocol. 

The  first  32  bytes  of  die  ANS  contain  the  name  of  the  node,  padded  on  die  right  with  zero 
bytes.  T  he  rest  of  the  packet  contains  blocks  of  information  expressed  in  16-bit  and  32-bit  words, 
low  byte  first  (pdpl  1/Lisp  machine  style).  The  low-order  half  of  a  32-bit  word  comes  first.  Since 
ANS  packets  contain  8-bit  data  (not  16-bit),  machines  such  as  pdplOs  which  store  numbers  high 
byte  first  will  have  to  shuffle  the  bytes  when  using  this  protocol.  The  first  16-hit  word  in  a  block 
is  its  identification.  The  second  16-bit  word  is  the  number  of  16-bit  words  to  follow.  TTic 
remaining  words  in  the  block  depend  on  the  identification. 

This  is  the  only  block  type  currently  defined.  All  items  arc  optional,  according  to  die  count 
field,  and  extra  items  not  defined  here  may  be  present  and  should  be  ignored.  Note  diat  items 
after  the  first  two  arc  32-bit  words. 

wordO  A  number  between  400  and  111  octal.  This  is  400  plus  a  subnet  number.  TTiis 

block  contains  information  on  this  host’s  direct  connection  to  diat  subnet. 

word  l  T  he  number  of  16-bit  words  to  follow,  usually  16. 

words  2-3  The  number  of  packets  received  from  this  subnet. 

words  4-5  T  he  number  of  packets  transmitted  to  this  subnet. 

words  6-7  T  he  number  of  transmissions  to  this  subnet  aborted  by  collisions  or  because  the 

receiver  was  busy. 

words  8-9  The  number  of  incoming  packets  from  this  subnet  lost  because  the  host  had  not 
yet  read  a  previous  packet  out  of  the  interface  and  consequently  die  interface 
could  not  capture  the  packet. 

words  10-11  The  number  of  incoming  packets  from  this  subnet  with  CRC  errors,  llte  e  were 
either  transmitted  wrong  or  damaged  in  transmission. 
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words  12*13  The  number  of  incoming  packets  from  this  subnet  which  had  no  CRC  error  when 
received,  but  did  have  an  error  after  being  read  out  of  the  packet  buffer.  flTiis 
error  indicates  cither  a  hardware  problem  with  the  packet  buffer  or  an  incorrect 
packet  length. 

words  14*15  The  number  of  incoming  packets  from  this  subnet  which  were  rejected  due  to 
incorrect  length  (typically  not  a  multiple  of  16  bits). 

words  16*17  The  number  of  incoming  packets  from  this  subnet  rejected  for  other  reasons  (c.g. 

too  short  to  contain  a  header,  garbage  byte-count,  forwarded  too  many  times.) 

If  the  identification  is  a  number  between  0  and  377  octal,  this  is  an  obsolete  format  of  block. 
The  identification  is  a  subnet  number  and  the  counts  arc  as  above  except  tJiat  they  are  only  16 
bits  instead  of  32,  and  consequently  may  overflow.  This  format  should  no  longer  be  sent  by  any 
hosts. 

Identification  numbers  of  1000  octal  and  up  are  reserved  for  future  use. 

5.2  Pulsar 

For  network  maintenance  purposes,  certain  network  nodes  support  a  simple  transaction  with 
contact  name  PULSAR,  which  controls  a  ’’pulsar”  feature.  'This  feature  periodically  transmits  a 
short  packet  which  can  be  used  to  test  and  adjust  cable  transceivers.  The  packet  consists  of  the 
three  header  words,  a  zero  word,  and  a  word  of  alternating  ones  and  zeros.  It  is  addressed  to 
host  177777  which  is  guaranteed  not  to  exist. 

The  returned  ANS  contains  a  single  character,  which  is  a  digit.  A  0  means  that  the  pulsar  is 
turned  off.  Any  other  digit  indicates  the  number  of  sixtieths  of  a  second  between  pulses.  Sending 
an  RFC  with  a  digit  as  an  argument  sets  the  state  of  the  pulsar  to  that  digit,  and  returns  an  ANS 
containing  the  new  state. 

5.3  Telnet  and  Supdup 

The  Telnet  and  Supdup  protocols  of  the  Arpanet  [THFNKT]  [SUPDUP]  exist  in  identical  form 
in  Chaosnet.  These  protocols  allow  access  to  a  computer  system  as  an  interactive  terminal  from 
another  network  node. 

The  contact  names  arc  TELNET  and  SUPDUP.  The  direct  borrowing  of  the  Telnet  and 
Supdup  protocols  was  eased  by  their  use  of  8-bit  byte  streams  and  only  a  single  connection.  Note 
that  these  protocols  define  their  own  character  sets,  which  differ  from  each  other  and  from  the 
t  'haosnet  stand  aid  character  set 

Chaosnet  contains  no  counterpart  of  the  1NR/INS  attention-getting  feature  of  the  Arpanet. 

I  lie  Telnet  protocol  sends  a  packet  with  opcode  201  in  place  of  the  INS  signal.  This  is  a 
controlled  packet  and  hence  docs  not  provide  the  "out  of  hand"  feature  of  the  Arpanet  INS, 
however  it  is  satisfactory  for  the  Telnet  "interrupt  process"  and  "discard  output"  operations  on  the 
kinds  of  hosts  attached  to  (  haosnet. 
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5.4  File  Access 

The  FIFK  protocol  is  primarily  used  by  l  isp  machines  to  access  files  on  network  file  servers. 
I  I  S  and  TOPS-20  arc  equipped  to  act  as  file  servers.  A  user  end  for  die  file  protocol  also  exists 
for  TOPS-20  and  is  used  for  general-purpose  file  transfer.  For  complete  documentation  on  the  file 
protocol,  sec  [FII.F|.  The  Arpanet  file  transfer  protocols  have  not  been  implemented  on  the 
Chaosnet  (except  through  the  Arpanet  gateway  described  below). 


5.5  Mail 

The  MAIL  protocol  is  used  to  transmit  inter-user  messages  through  the  Chaosnet.  The 
Arpanet  mail  protocol  was  not  used  because  of  its  complexity  and  poor  state  of  documentation. 
ITiis  simple  protocol  is  by  no  means  the  last  word  in  mail  protocols;  however,  it  is  adequate  for 
the  mail  systems  we  presently  possess. 

The  sender  of  mail  connects  to  contact  name  MAH.  and  establishes  a  stream  connection.  It 
then  sends  the  names  of  all  the  recipients  to  which  die  maii  is  to  be  sent  at  (or  via)  die  server 
host.  The  names  are  sent  one  to  a  line  and  terminated  by  a  blank  line  (two  carriage  returns  in  a 
row).  The  Lisp  Machine  character  set  is  used.  A  reply  (see  below)  is  immediately  returned  for 
each  recipient.  A  recipient  is  typically  just  the  name  of  a  user,  but  it  can  be  a  uscr-atsign-host 
sequence  or  anything  else  acceptable  to  the  mail  system  on  the  server  machine.  After  sending  the 
recipients,  the  sender  sends  the  text  of  the  message,  terminated  by  an  HOF.  After  die  mail  has 
been  successfully  swallowed,  a  reply  is  sent.  After  die  sender  of  mail  has  read  the  reply,  both 
sides  close  the  connection. 

In  die  MAIL  protocol,  a  reply  is  a  signal  from  the  server  to  the  user  (or  sender)  indicating 
success  or  failure.  The  first  character  of  a  reply  is  a  plus  sign  for  success,  a  minus  sign  for 
permanent  failure  (c.g.  no  such  user  exists),  or  a  percent  sign  for  temporary  failure  (c,g.  unable  to 
receive  message  because  disk  is  full).  The  rest  of  a  reply  is  a  human-readable  character  string 
explaining  the  situation,  followed  by  a  carriage  return. 

'Flic  message  text  transmitted  through  die  mail  protocol  normally  contains  a  header  formatted 
in  the  Arpanet  standard  fashion.  [RFC733| 


5.6  Send 

The  SFNI)  protocol  is  used  to  transmit  an  interactive  message  (requiring  immediate  attention) 
between  users.  The  sender  connects  to  contact  name  SLN1)  at  die  machine  to  which  the  recipient 
is  logged  in.  The  remainder  of  the  RFC  packet  contains  die  name  of  the  person  being  sent  to. 
A  stream  connection  is  opened  and  the  message  is  transmitted,  followed  by  an  FOIL  Both  sides 
close  after  following  die  end-of-data  protocol  described  in  section  4.4,  page  24.  I  he  tact  that  the 
RFC  was  responded  to  affirmatively  indicates  that  the  recipient  is  in  fact  present  and  accepting 
messages.  I  he  menage  text  should  begin  with  it  suitable  header,  naming  the  user  that  sent  the 
message.  The  standard  for  such  headeis,  not  cuncnlly  adhered  to  by  all  hosts,  is  one  line 
formatted  as  in  the  following  example; 

MounMfll  I  MC  l > /  1  f) / 8  I  ()?:?():  17 

Aiitomatk  n  ph  to  the  wilder  inn  he  imp!-  men  led  In  searching  tot  the  first  "<u  "  and  using  the 
SIM)  pioluol  to  lit"  host  following  the  ”10"  with  the  argument  preceding  it. 
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5  7  Name 

rITic  Namc/Fingcr  protocol  of  the  Arpanet  [FINGFR]  exists  in  identical  form  on  the  Chaosnet. 
Both  Lisp  machines  and  timesharing  machines  support  this  protocol  and  provide  a  display  of  the 
uscr(s)  currently  logged  in  to  them. 

ITic  contact  name  is  NAME  which  can  be  followed  by  a  space  and  a  string  of  arguments  like 
the  "command  line"  of  the  Arpanet  protocol.  A  stream  connection  is  established  and  the  "finger” 
display  is  output  in  Lisp  Machine  character  set,  followed  by  an  EOF. 

Lisp  Machines  also  support  the  FINGHR  protocol,  a  simple-transaction  version  of  the  NAME 
protocol.  An  RFC  with  contact  name  FINGER  is  transmitted  and  the  response  is  an  ANS 
containing  the  following  items  of  information  separated  by  carriage  returns:  the  logged-in  user  ID, 
the  location  of  the  terminal,  the  idle  time  in  minutes  or  hours-colon-minutes,  the  user’s  full 
name,  and  the  user’s  group  affiliation. 


5.8  Time 

The  Time  protocol  of  the  Arpanet  [TIME]  exists  on  Chaosnet  as  a  simple  transaction.  An 
RFC  to  contact  name  TIME  evokes  an  ANS  containing  the  number  of  seconds  since  midnight 
Greenwich  Mean  Time,  Jan  1,  1900  as  a  32-bit  number  in  four  8-bit  bytes,  least-significant  byte 
first.  Some  computers— Lisp  machines,  for  example— which  don't  have  hardware  calendar-clocks 
use  this  protocol  to  find  out  the  date  and  time  when  they  first  come  up. 

5.9  Arpanet  Gateway 

ITiis  protocol  allows  a  Chaosnet  host  to  access  almost  any  service  on  the  Arpanet  The 
gateway  server  runs  on  each  ITS  host  that  is  connected  to  both  networks.  It  creates  an  Arpanet 
connection  and  a  Chaosnet  connection  and  forwards  data  bytes  from  one  to  the  other.  It  also 
provides  for  a  one-way  auxiliary  connection,  used  for  the  data  connection  of  the  Arpanet  File 
Transfer  Protocol. 

The  RFC  packet  contains  a  contact  name  of  ARPA,  a  space,  the  name  of  the  Arpanet  host  to 
be  connected  to,  optionally  followed  by  a  space  and  the  contact-socket  number  in  octal,  which 
defaults  to  1  if  omitted.  The  Arpanet  Initial  Connection  Protocol  is  used  to  establish  a  bi¬ 
directional  8-bit  connection. 

If  a  data  packet  with  opcode  201  (octal)  is  received,  an  Arpanet  INS  signal  will  be 
transmitted.  Any  data  bytes  in  this  packet  are  transmitted  normally. 

If  a  data  packet  with  opcode  210  (octal)  is  received,  an  auxiliary  connection  on  each  network 
is  opened.  The  first  eight  data  bytes  are  the  Chaosnet  contact  name  for  the  auxiliary  connection: 
the  user  should  send  an  RFC  with  this  name  to  the  server.  The  next  lour  data  bytes  are  die 
Ai panel  socket  number  to  be  connected  to,  in  the  wrong  order,  most -significant  h\ tc  first.  The 
!>\le  si/e  of  the  auxiliary  connection  is  8  bits. 

I  he  normal  closing  oT  an  At  panel  ronnei  lion  corn*- ponds  to  an  l  ()T  packet.  Closing  due  to 
an  emu.  such  as  I  lost  Dead,  toncspoiids  to  a  (IS  packet. 
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5.10  Dover 

A  press  file  may  be  sent  to  the  Dover  printer  by  connecting  to  contact  name  DOVER  at  host 
AI-CHAOS-11.  This  host  provides  a  protocol  translation  service  which  translates  from  Chaosnet 
stream  protocol  to  the  EFTP  protocol  spoken  by  the  Dover  printer.  Only  one  file  at  a  time  can 
be  sent  to  the  Dover,  so  an  attempt  to  use  this  service  may  be  refused  by  a  Cl  .S  packet 

containing  the  string  "BUSY".  Once  the  connection  has  been  established,  the  press  file  is 

transmitted  as  a  sequence  of  8-bit  bytes  in  data  packets  (opcode  200).  It  is  necessary  to  provide 
packets  rapidly  enough  to  keep  the  Dovers  program  (Spruce)  from  timing  out;  a  packet  every 
five  seconds  suffices.  Of  course,  packets  are  normally  transmitted  much  more  rapidly. 

Once  the  file  has  been  transmitted,  an  FOP  packet  must  be  sent.  'The  Iran  mitter  must  wait 
for  that  FOF  to  be  acknowledged,  send  a  second  one,  then  close  die  connection.  The  two  FOF‘s 
are  necessary  to  provide  the  proper  connection-closing  sequence  for  the  EFTP  protocol.  Once  the 
press  file  has  been  transmitted  to  the  Dover  in  this  way  and  stored  on  the  Dover’s  local  disk,  it 
will  be  processed  and  prepared  for  printing,  and  then  printed. 

If  an  error  message  is  returned  by  the  Dover  while  the  pr*c$s  file  is  being  transmitted,  it  will 
be  reported  back  through  the  Chaosnet  as  a  f.OS  containing  the  text  of  the  error  message.  Such 

errors  arc  fairly  common;  the  sender  of  the  press  file  should  be  prepared  to  retry  die  operation  a 

few  times. 

Most  programs  that  send  press  files  to  die  Dover  first  wait  for  the  Dover  to  be  idle,  using  the 
Foreign  Protocol  mechanism  of  Chaosnet  to  check  the  status  of  die  Dover.  This  is  optional,  but 
is  courteous  to  other  users  since  it  prevents  printing  from  being  held  up  while  additional  files  arc 
sent  to  the  Dover  and  queued  on  its  local  disk. 

It  would  be  possible  to  send  to  a  press  file  to  the  Dover  using  its  EFTP  protocol  through  the 
Foreign  Protocol  mechanism,  rather  than  using  the  Al -CHAOS-*  11  gateway  service.  This  is  not 
usually  done  because  EFTP,  which  requires  a  handshake  for  every  packet,  tends  to  be  very  slow 
on  a  timesharing  system. 
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6.  Using  Foreign  Protocols  in  Chaosnet 

As  seen  above,  foreign  protocols  which  arc  based  on  the  idea  of  a  bidirectional  (or 
unidirectional)  stream  of  8-bit  bytes  can  simply  be  adopted  wholesale  into  Chaosnet,  using  a 
Chaosnet  stream  connection  instead  of  whatever  stream  protocol  the  protocol  was  originally 
designed  for.  lliis  was  done  with  the  Arpanet  Telnet  protocol,  for  example. 

When  using  such  protocols  between  a  Chaosnet  process  and  a  process  on  a  foreign  network,  a 
protocol-translating  gateway  stands  at  the  boundary  between  the  two  networks  and  has  a 
connection  on  both  networks.  Bytes  received  from  one  connection  arc  transmitted  out  the  other. 
If  the  protocol  uses  any  features  besides  a  simple  stream  of  bytes,  for  instance  special  out-of-band 
signals,  these  are  translated  appropriately  by  the  gateway.  rHie  connection  is  initially  set  up  by 
the  user  end  connecting  explicitly  to  the  protocol-translating  gateway  and  demanding  of  it  a 
certain  service  from  a  certain  host  on  the  other  network;  the  gateway  then  opens  the  appropriate 
pair  of  connections.  For  an  example  of  this,  refer  to  the  Arpanet  gateway  (sec  section  5.9,  page 
30). 


However,  there  are  many  packet-oriented  protocols  in  the  world  and  sometimes  it  is  desirable 
to  access  these  protocols  at  the  packet  level  rather  than  the  connection  level,  and  to  transport  the 
packets  of  these  protocols  through  Chaosnet  links  without  using  a  Chaosnet  connection.  For 
example,  there  are  gateways  attached  to  Chaosnet  which  provide  connections  to  other  networks 
that  use  PUP  and  Internet  as  their  packet  protocols.  User  processes  in  Chaosnet  hosts  may  talk  to 
these  other  networks  in  those  networks’  own  protocols  by  using  the  foreign -protocol  protocol  of 
Chaosnet. 

A  foreign  packet  is  transmitted  through  Chaosnet  by  storing  it  in  the  data  field  of  an  UNO 
packet.  The  foreign  packet  is  regarded  as  being  composed  of  8-bit  bytes.  The  source  and 
destination  addresses  of  the  UNC.  packet  arc  used  in  the  usual  fashion  to  control  the  delivery  of 
the  packet  within  Chaosnet.  The  packet  number  and  acknowledgement  fields  of  the  packet  header 
arc  not  used  for  their  normal  purposes,  since  this  packet  is  not  associated  with  a  Chaosnet  stream 
connection.  By  convention,  the  acknowledgement  field  of  the  packet  contains  a  protocol  number. 
The  number  100000  octal  means  Internet  and  the  number  100001  octal  means  PUP.  Other 
numbers  will  be  assigned  as  needed.  'ITic  packet  number  field  of  the  packet  can  be  used  for  any 
purpose. 

If  a  user  process  transmits  an  UNC  packet  through  a  Chaosnet  channel  which  is  in  the  Closed 
state  (see  section  4.6.  page  25),  the  channel  goes  into  the  Foreign  state  and  the  NCP  assumes  that 
the  user  is  not  talking  normal  Chaosnet  protocol,  hut  is  using  Chaosnet  to  transport  packets  of 
some  other  protocol.  The  NCP  fills  in  the  source  address  and  index  in  these  packets,  hut  believes 
whatever  destination  address  atid  index  arc  placed  in  the  packet  by  the  user.  The  packet  number 
and  acknowledgement  fields  of  the  UNC  packets  arc  not  touched  by  the  NCP.  Any  incoming 
UNC  packets  addressed  to  the  users  index  on  this  host  will  be  given  to  the  user,  regardless  of 
their  source  addrcss/iiulcx;  it  is  up  to  the  user  program  to  filter  out  any  unwanted  packets.  The 
NCP  should  also  provide  a  way  for  one  user  to  receive  tiny  unclaimed  incoming  UNC  packets,  so 
that  rendezvous  siibprotocols  of  foreign  protocols  may  be  simulated. 

When  a  packet-translating  gateway  to  a  foreign  network  receives  an  UNC  packet  with  the 
jppmpn.iie  protocol  number,  it  extracts  the  foreign  packet  Imm  the  data  held  and  fires  it  into  the 
Ihictgn  nctwoik.  When  it  receives  [jackets  hum  the  Ibicien  mlwork,  it  maps  the  destination 
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address  of  die  packet  into  a  Chaosnet  address  and  index  in  some  suitable  fashion,  encapsulates 
tiic  packet  in  an  UNC,  and  launches  it  into  Chaosnet. 

For  PUP  the  address  mapping  is  straightforward,  since  PUP  and  Chaosnet  use  similar 
addressing  techniques  [KTUHRNET].  The  host  address  spaces  are  die  same.  The  Chaosnet  index 
maps  directly  into  the  low-order  16  bits  of  the  PUP  port  number,  and  the  high-order  16  bits  are 
zero.  When  a  PUP  is  encapsulated  in  a  Chaosnet  packet,  its  PIJP  header  duplicates  the  addresses 
in  the  Chaosnet  header.  When  a  PUP  is  received  by  a  PUP/Chaosnet  gateway  a  Chaosnet 
header  can  easily  be  constructed  from  die  PUP  header.  I  lie  AI-CIIAOS-11  is  attached  to  the 
MU'  Chaosnet  and  die  MU'  Kthcrnct  and  provides  a  PUP/Chaosnet  gateway  It  advertises  to 
each  network  its  ability  to  route  packets  to  host  addresses  in  die  other  network,  using  that 
network’s  routing  protocols.  When  it  receives  a  packet  from  one  network  dial  is  destined  for  the 
other,  it  docs  the  appropriate  encapsulation  or  de-encapsulation  and  sends  the  packet  on  its  way. 
Al-CHAOS-11  also  acts  as  a  bridge  between  several  Chaosnet  subnets  and  provides  a  protocol- 
translating  gateway  for  sending  Press  files  to  the  Dover  printer  (a  protocol-translating  gateway  is 
necessary  for  this  application  because  the  printer’s  native  protocol,  which  could  be  used  through 
die  foreign-protocol  protocol,  cannot  be  implemented  efficiently  under  a  timesharing  system). 

in  the  ease  of  Internet,  only  protocols  built  on  die  idea  of  ports  can  be  straightforwardly 
supported  without  a  table  of  connections  in  the  gateway.  The  Internet  address  space  includes  the 
Chaosnet  host  address  space  as  a  subset  but  docs  not  provide  any  address  breakdown  within  a 
host  unless  ports  are  used.  However,  it  appears  that  most  protocols  are  built  on  a  protocol  that 
uses  ports,  such  as  the  User  Datagram  Protocol  [UDP]  or  the  Transmission  Control  Protocol 
[TCP]. 

In  the  ease  of  foreign  protocols  other  than  PUP,  where  the  addressing  structure  is  not 
identical  to  Chaosnet,  a  program  must  somehow  know  the  Chaosnet  address  of  a  packet- 
translating  gateway  to  the  foreign  network.  By  sending  UNC  packets  to  this  gateway,  a  user 
program  can  initiate  connections  to  processes  on  that  other  network  without  requiring  his  local 
NCP  (nor  any  bridges  involved  in  routing  die  packets)  to  know  anything  about  the  protocol  he  is 
using.  If  die  inter-network  gateway  translates  rendezvous  protocols  appropriately,  connections  may 
be  initiated  in  the  reverse  direction  also — from  a  user  process  on  the  foreign  network  to  a  server 
for  the  foreign  protocol  that  resides  on  a  Chaosnet  host. 

The  foreign-protocol  protocol  may  also  be  used  between  two  user  processes  on  Chaosnet,  with 
no  foreign  network  involved,  if  they  simply  wish  to  speak  a  different  protocol  from  Chaosnet. 
They  arc  on  their  own  for  a  rendezvous  mechanism,  however,  unless  they  use  a  Chaosnet  simple 
transaction  for  rendezvous  or  otherwise  have  some  way  of  convey  mg  their  addresses  and  index 
numbers  to  each  other. 

When  foreign  packets  arc  too  large  to  (it  in  the  data  field  of  a  Chaosnet  packet  (more  dian 
488  bytes),  the  user  program  and  the  packet-translating  gateway  must  agree  on  a  technique  for 
dividing  packets  into  fragments  and  reassembling  them,  unless  the  foreign  protocol  itself  pro' ides 
for  this,  as  Internet  does.  The  packet-number  field  in  an  UNC  packet  is  available  for  use  by 
such  a  technique,  since  UNC  packets  are  not  normally  numbered.  This  is  not  a  problem  with 
Ft i|\  since  it  provides  a  ptnlocol  by  which  parties  to  a  conn»viion  and  gateways  may  complain 
about  ovetly  Imge  packets  and  specify  the  maximum  packet  size  to  be  used. 

UNC  packets  not  associated  with  a  coinusiion  ate  useful  for  other  things  besides  encapsulating 
Juteitut  protocols.  Any  application  which  wants  to  use  (  Iikmio  is  simply  a  picket  n.uisuiKsion 
medium,  essentially  the  raw  li. adware.  d)*>,|ld  use  UNC  panels  mi  that  its  packet1,  do  not 
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interfere  with  standard  packets  and  so  that  the  standard  routing  mechanisms  may  be  used.  For 
example,  the  MIT  Architecture  Machine  uses  UNC  packets  to  communicate  with  non-stream- 
oriented  I/O  devices  such  as  graphic  tablets.  Here  Chaosnet  is  being  used  as  an  I/O  bus  which 
may  be  attached  to  more  than  one  computer.  Numbers  between  140000  and  177777  octal  in  the 
acknowledgement  field  of  an  UNC  packet  are  reserved  for  such  applications.  Note  that  this 
number  is  not  part  of  the  protocol;  it  is  simply  a  hint  about  what  a  packet  is  being  used  for. 
Normally  no  program  that  is  not  specifically  supposed  to  deal  with  such  packets  would  ever 
receive  one. 
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7.  Hardware  Programming  Documentation 

r  This  section  describes  the  Unibus  version  of  the  Chaosnet  interface,  which  attaches  to  pdplls 

and  I.isp  Machines.  The  interface  contains  one  buffer  which  holds  a  received  packet  and  a  second 
buffer  which  holds  a  packet  to  be  transmitted.  Packets  arc  moved  between  these  butlers  and  the 
r  computer  under  program  control.  Direct  memory  access  (DMA)  is  not  used;  the  small  gain  in 

performance  was  not  thought  to  be  worth  the  extra  hardware  complexity.  The  usual  performance 
penalty  of  programmed  1/(3  is  not  incurred  since  the  packet  buffers  can  transfer  data  at  tiic  full 
speed  of  the  computer  and  neither  busy  waiting  nor  multiple  interrupts  arc  required. 

r  'To  transmit  a  packet,  successive  16-bit  words  of  the  packet  are  written  into  die  outgoing 

packet  buffer.  The  last  word  to  be  written  is  the  cable  address  of  the  destination  of  the  packet, 
j  or  0  to  broadcast  it.  The  hardware  is  then  told  to  initiate  transmission.  It  waits  until  the  cable  is 

^  not  busy  and  this  node’s  turn  to  transmit  arrives,  then  shifts  the  packet  out  onto  the  cable.  At 

the  completion  of  transmission  transmit-done  is  set  and  the  computer  is  interrupted.  If 
(,  -  transmission  is  aborted  by  a  collision,  transmit-done  and  transmit-abort  arc  set  and  the  computer 

p  is  interrupted.  As  the  packet  is  written  into  the  outgoing  packet  buffer,  a  16-bit  cyclic  redundancy 

[  checksum  is  computed  by  the  hardware.  This  checksum  is  transmitted  with  the  packet  and 

checked  by  the  receiver. 

k-  .  To  receive  a  packet,  die  clcar-rcccivcr  bit  is  asserted  by  the  program.  The  next  packet  on  the 

r 

,  cable  which  is  addressed  to  this  node,  or  is  broadcast,  will  be  stored  into  the  incoming  packet 

buffer.  After  the  packet  has  been  stored,  the  computer  is  interrupted.  The  packet  bulfer  will 
then  not  be  changed  until  the  next  clear- receiver  operation  is  performed,  giving  the  computer  a 
i  chance  to  read  out  the  packet.  If  a  packet  appears  on  the  cable  addressed  to  this  node  while  the 

t  incoming  packet  buffer  is  busy,  a  collision  is  simulated  so  as  to  abort  the  transmission.  As  a 

1  packet  is  stored  into  the  incoming  packet  buffer,  the  16-bit  cyclic  redundancy  checksum  is 

‘  checked,  and  it  is  checked  again  as  the  packet  is  read  out  of  the  packet  buffer.  This  provides  full 

checking  for  errors  in  the  network  and  in  the  packet  buffers. 

j.1 

\  The  standard  interrupt-vector  address  for  the  Chaosnet  interface  is  270.  The  standard  interrupt 

priority  level  is  5.  The  standard  Unibus  address  is  764140.  These  arc  the  device  registers; 

!  764140  ( otmuunl/ Status  Register 

[  j  This  register  contains  a  number  of  bits,  in  the  usual  pdpll  style.  All  rcad/write  bits  are 

J  initialized  to  zero  on  power-up.  Identified  by  their  masks,  these  are: 

1  Timer  Interrupt  Unable  (rcad/writc).  Tnables  interrupts  from  the  interval  timer 
present  in  some  versions  of  the  interface  (not  dev  ribed  here). 

'  2  l  oop  Hack  (rcad/writc).  If  this  bit  is  1.  the  cable  and  transceiver  are  not  used 

i  and  the  interface  is  looped  back  to  itself.  This  is  for  maintenance. 

*  t  4  Spy  (rcad/writc).  II'  this  hit  is  1,  the  itueifacc  will  receive  all  packets  regardless 

of  their  destination.  I  his  is  for  maintenance  and  network  monitoring. 

r  j  10  Clear  Receiver  (wiite  only).  Writing  a  1  into  this  bit  clears  Receive  Done  and 

j  enables  the  receiver  to  receive  another  packet, 

20  Receive  Interrupt  Unable  (rcad/writc).  II  Receive  Done  and  ReuTe  Interrupt 
j.iuMe  me  both  I.  the  lompuu-i  is  intermixed. 
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764142 

764142 

764144 

764146 

764152 


40  Transmit  Interrupt  finable  (rcad/writc).  If  Transmit  Done  and  Transmit 
Interrupt  Knablc  arc  both  1,  the  computer  is  interrupted. 

100  Transmit  Abort  (read  only).  'This  bit  is  1  if  the  last  transmission  was  aborted, 
by  a  collision  or  because  the  receiver  was  busy. 

200  Transmit  Done  (read  only).  TTiis  bit  is  set  to  1  when  a  transmission  is 
completed  or  aborted,  and  cleared  to  0  when  a  word  is  written  into  the  outgoing 
packet  buffer. 

400  Clear  Transmitter  (write  only).  Writing  a  1  into  this  bit  stops  the  transmitter 
and  sets  Transmit  Done.  TTiis  is  for  maintenance. 

17000  Tost  Count  (read  only).  These  4  bits  contain  a  count  of  the  number  of  packets 
which  would  have  been  received  if  the  incoming  packet  buffer  had  not  been 
busy.  Setting  Clear  Receiver  resets  the  lost  count  to  0. 

20000  Reset  (write  only).  Writing  a  1  into  this  bit  completely  resets  the  interface,  just 
as  at  power  up  and  Unibus  Initialize. 

40000  CRC  Hrror  (read  only).  If  this  bit  is  1  the  receiver’s  cyclic  redundancy 
checksum  indicates  an  error.  This  bit  is  only  valid  at  two  times:  when  the 
incoming  packet  buffer  contains  a  fresh  packet,  and  when  the  packet  has  been 
completely  read  out  of  the  packet  buffer. 

100000  Receive  Done  (read  only),  A  1  in  this  bit  indicates  that  the  incoming  packet 
buffer  contains  a  packet. 

My  Address  (read) 

Reading  this  location  returns  the  network  address  of  this  interface  (which  is  contained  in  a 
set  of  DIP  switches  on  the  board). 

Write  buffer  (write) 

Writing  this  location  writes  a  word  into  the  outgoing  packet  buffer.  The  last  word  written 
is  the  destination  address. 

Read  Buffer  (read  only) 

Reading  this  location  reads  a  word  from  the  incoming  packet  buffer.  The  last  three  words 
read  arc  the  destination  address,  the  source  address,  and  the  checksum. 

Bit  Count  (read  only) 

This  location  contains  the  number  of  bits  in  the  incoming  packet  buffer,  minus  one. 
After  the  whole  packet  has  been  read  out,  it  will  contain  7777  (a  12-bit  minus-one). 

Start  Transmission  (wad  only) 

Rending  litis  location  initiates  transmission  of  the  packet  in  the  outgoing  packet  buffer. 
The  v  tine  lead  is  the  network  address  of  (his  interface.  This  method  for  .starting 
transmission  may  seem  strange,  but  it  makes  it  easier  for  the  hardware  to  get  the  source 
address  into  the  packet. 
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8.  The  ITS  Implementation 

8.1  System  Calls 

Note  that  the  NETWRK  subroutine  package,  page  42,  provides  a  convenient  interface  to  most 
of  these  system  calls  for  the  assembly-language  programmer. 

8.1.1  Opening  I/O  Channels 

Since  ITS  I/O  Channels  arc  unidirectional,  a  Chaosnet  connection  is  represented  by  a  pair  of 
channels,  one  for  input  and  one  for  output.  Operations  that  arc  not  inherently  directional,  such 
as  finding  out  the  state  of  the  connection,  may  be  done  on  cither  channel  (it  makes  no 
difference). 

Unlike  every  other  device,  you  do  not  obtain  these  channels  with  the  OPEN  system  call. 
Instead  a  special  system  call,  CHAOSO,  is  provided.  This  docs  not  open  a  connection;  it  simply 
gives  you  a  pair  of  channels  and  a  potential  connection,  in  the  Closed  suite,  which  can  be  opened 
by  transmitting  a  packet  (an  RFC  for  instance)  through  the  output  channel. 

CHAOSO  takes  three  arguments:  the  input  channel  number,  the  output  channel  number,  and 
the  receive  window'  size.  If  either  channel  is  currently  open  it  is  closed  first  (just  as  with  OPEN). 
CHAOSO  returns  no  values.  Error  6  (device  full)  is  signalled  if  the  system's  connection  tabic  is 
full. 


8.1.2  Input  and  Output 

Input  and  output  can  be  done  on  a  Chaosnet  connection  in  terms  of  either  packets  or  8-bit 
bytes.  8-bit  byte  I/O  is  usually  done  with  the  SIOT  system  call;  the  10T  system  call  or  the  .IOT 
uuo  may  also  be  used — the  channel  behaves  as  if  it  had  been  opened  in  unit  mode.  8-bit  byte 
output  is  collected  by  the  system  into  packets  containing  the  maximum  allowed  number  of  bytes; 
when  a  packet  is  full  it  is  transmitted  with  the  standard  data  opcode  (200).  Until  a  full  packet’s 
worth  of  bytes  have  been  output  nothing  will  be  transmitted  unless  the  FORCE  system  call  is 
used.  8-bit  input  comes  from  packets  with  the  data  opcode  (200).  If  an  EOF  packet  is  received, 
the  standard  ciuEof-file  behavior  will  occur— IOT  will  return  the  I *01  •  character  (-1..3)  and  SIOT 
will  return  with  a  non-zero  residual  byte  count.  If  some  other  kind  of  packet  is  received,  an  IOC 
error  will  be  signalled  (sec  below).  If  PKTIOT  (sec  below)  is  used  to  read  out  a  non-data  packet, 
stream  input  may  be  continued  past  it. 

Hit  1.4  in  the  control  bits  is  "don’t  hang”  mode  for  both  input  and  output.  When  SIOT  is 
done  with  t his  bit  specified,  and  no  input  is  available  or  the  output  window  is  full,  it  will  simply 
return  without  irunsfoiiing  the  full  number  of  lutes  specified.  The  byte-pointer  and  byte-count 
arguments  to  SIOT  aie  updated  past  the  bytes  that  were  transferred.  When  input  IOT  k  done  in 
"don't  hang"  mode,  and  no  input  is  «i\  til.ihl«\  die  EOI  character  (-1,3)  is  returned.  Output  IOT 
should  not  be  done  in  "don't  hang"  mode  since  it  has  no  way  to  indicate  that  it  did  not  transmit 
anything.  It  a  non  d  iia  packet  is  lem-.cd  "don't  hang"  mode  will  behave  the  same  as  if  there 
was  no  input  available. 
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Before  doing  8-bit  byte  I/O,  the  user  program  must  open  a  Chaosnet  stream  connection  by 
transmitting  and  receiving  the  appropriate  RFC,  LSN,  or  OPN  packets  and  following  the  protocol 
described  on  page  21.  The  NETWRK  subroutine  package  can  be  useful  for  this. 

Input  and  output  can  be  done  in  terms  of  packets  by  using  the  PKTIOT  system  call.  The  first 
argument  is  the  I/O  channel  number  and  the  second  is  the  address  of  the  packet  to  be 
transmitted  or  of  a  126.-word  buffer  to  contain  the  packet  to  be  received.  No  values  arc  returned. 

Input  PKTIOT  will  return  data  packets  and  the  following  types  of  control  packets:  RFC, 
OPN,  FW1),  ANS,  CCS,  LOS,  EOF,  and  UNC.  The  other  types  of  control  packets  arc  for  the 
NCP's  internal  use  only.  If  no  input  packets  arc  available,  PKTIOT  will  wait.  If  the  connection 
is  in  a  bad  state,  an  IOC  error  will  be  signalled.  This  is  discussed  in  the  next  section. 

Output  PKTIOT  will  accept  data  packets  and  CIS,  EOF,  and  UNC  packets  if  the  connection 
is  open.  Transmitting  an  UNC  packet  when  the  connection  is  closed  puts  it  into  the  Foreign 
Protocol  state.  RFC,  LSN,  OPN,  FW1),  and  ANS  packets  may  be  transmitted  if  the  connection 
is  in  the  appropriate  state.  Transmitting  a  bad  packet  type  or  transmitting  when  the  connection  is 
in  the  wrong  state  signals  an  IOC  error  (see  the  next  section).  Normally  the  user  sets  only  the 
opcode  and  number  of  bytes  fields  in  die  packet  header;  PKTIOT  fills  in  die  rest.  When  sending 
an  RFC,  the  user  specifics  the  destination-host  field  and  the  system  remembers  it.  When  sending 

an  UNC,  the  user  specifics  everything  but  the  source  host  and  index. 

Note  that  PKTIOT  docs  not  synchronize  with  8-bit  byte  I/O.  If  a  partial  packet’s  worth  of 
bytes  have  been  output,  and  then  a  packet  is  output  with  PKTIOT,  that  packet  will  get  ahead  of 

those  bytes.  The  FORCE  system  call  can  be  used  to  change  this.  If  a  partial  packet’s  worth  of 

bytes  have  been  input,  and  then  a  PKTIOT  is  done,  diosc  bytes  will  remain  available  to  the 

stream  and  PKTIOT  will  read  the  next  packet  after  them. 

8.13  Interrupts 

I/O  (second-word)  interrupts  occur  if  enabled  when  an  I/O  operation  formerly  would  have 
hung  but  now  will  not.  In  other  words,  an  interrupt  occurs  on  the  input  channel  when  a  packet 

arrives  while  there  arc  no  input  packets  available,  if  die  packet  is  of  a  type  that  input  PKTIOT 

would  return.  An  interrupt  occurs  on  the  output  channel  if  the  window  is  full  and  an 
acknowledgement  arrives  which  makes  some  space  in  the  window.  Completely  interrupt-driven 
I/O  can  easily  be  programmed  for  the  Chaosnet,  using  the  WHVINT  system  call  (see  below). 

An  interrupt  also  occurs  on  the  input  channel  when  die  connection  state  changes. 

A  %PIIOC  interrupt  (also  tailed  an  "IOC  error")  occurs  if  any  of  a  variety  of  illegal 
operations  is  performed.  IOC  error  3  (non- recoverable  data  error)  is  signalled  if  a  packet  is 
transmitted  wiih  PKTIOT  and  it  has  an  illegal  si/e  or  opcode  in  the  header.  IOC  error  12  octal 
(channel  in  illegal  mode)  is  signalled  if  byte  or  packet  input  or  output  is  done  with  the 
connection  in  die  wrong  state,  or  if  byte  input  is  done  and  a  packet  other  than  a  normal  data 
packet  or  I  OF  is  found. 
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8.1.4  Miscellaneous  Operations 

The  CLOSE  system  call,  or  the  .CLOSE  uuo,  may  be  used  to  close  the  I/O  channels  and  the 
connection.  When  both  channels  arc  closed,  all  buffers  and  other  information  associated  with  the 
connection  arc  immediately  discarded.  If  the  connection  is  open  a  CLS  packet  is  transmitted. 
You  can  also  transmit  a  CLS  yourself,  with  an  explanatory  message  in  it,  before  doing  the 

CLOSE. 

The  FORCE  system  call,  or  the  .NETS  uuo,  can  be  used  on  an  output  channel.  If  there  is 
buffer  containing  a  partial  packet’s  worth  of  8-bit  byte  output,  it  is  transmitted  as  a  packet  of  less 
than  the  maximum  size. 

Hie  FINISH  system  call  first  does  a  FORCE  and  then  waits  for  all  packets  that  have  been 
transmitted  to  be  acknowledged. 

The  RESET  system  call,  and  die  .RESET  uuo,  arc  ignored,  as  on  most  devices.  The  RCHST 
and  RFNAME  system  calls,  and  the  .RCHST  uuo,  return  die  standard  information  for  a  non-file 
device,  with  device-name  CHAOS:.  No  device-dependent  information  is  returned. 

The  WHYINT  system  call,  given  either  the  input  channel  or  the  output  channel  of  a  Chaosnet 
connection,  returns  a  lot  of  useful  device-dependent  information  about  the  connection: 

val  1  The  device  code,  which  is  the  value  of  the  symbol  %WYCHA. 

val  2  The  state  of  the  connection.  Symbols  for  the  connection  stales  start  with  foe  prefix  %CS: 
%CSCLS  Closed  (or  never  opened). 

%CSLSN  I.istening  for  an  incoming  RFC. 

%CSRFC  RFC  received  while  listening;  neither  accepted  nor  rejected  yet. 

%CSRFS  RFC  sent,  awaiting  acceptance,  rejection,  or  answer. 

%CSOPN  Open. 

%CSLOS  Broken  by  receipt  of  a  LOS  packet. 

%CSINC  Broken  by  "incomplete  transmission"  (no  response  from  foreign  host  for  a 
long  time). 

%CSFRN  Using  a  foreign  protocol,  encapsulated  in  UNC  packets. 

val  3  The  left  half  is  the  number  of  available  input  packets.  This  does  not  count  out-of-order 
packets.  I  his  number  is  increased  by  one  if  there  is  buffered  input  available  for  8-bit 
byte  input.  T  his  number  is  zero  if  the  Chaosnet  connection  is  directly  connected  to  a 
STY  (see  STYNET). 

The  right  half  is  the  number  of  output  packets  which  have  not  yet  been  acknowledged 
and  hence  are  occupying  space  in  the  window. 

val  4  T  he  loll  half  is  the  receive  window  m/o  and  the  right  half  is  the  transmit  window  si/e. 

val  5  The  left  lull  is  the  input  rhami',l  number  and  the  tight  half  is  the  output  channel 
number.  Iho* e  nnmbcis  aic  I  il  the  channel  lus  been  CLOfiLd  or  IOPUSI  led. 
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The  NETBLK  system  call  works  similarly  on  the  Chaosnet  as  on  the  Arpanet.  The  first 
argument  is  a  channel  number  (input  or  output).  The  second  argument  is  a  connection  state  code. 
The  third  argument,  which  is  optional,  is  a  timeout  in  30ths  of  a  second.  If  it  is  not  immediate 
it  is  modified.  NETBLK  hangs  until  the  connection  state  is  different  from  the  specified  suite  or 
the  timeout  (if  specified)  elapses.  Two  values  arc  returned:  the  current  state  of  the  connection 
and  the  amount  of  time  left 

The  STVNET  system  call  works  similarly  on  the  Chaosnet  cs  on  the  Arpanet.  It  allows  a 
Chaosnet  connection  and  a  STY  (pseudo  terminal)  to  be  connected  together  so  that  a 
Tclnct/Supdup  server  program  can  provide  efficient  service.  1'hc  arguments  arc: 

arg  1  '1'hc  STY  channel  number. 

arg2  The  Chaosnet  input  channel  number  to  connect  it  to,  or  T  to  disconnect  it. 

arg  3  'The  Chaosnet  output  channel  number.  This  is  not  actually  used  on  the  Chaosnet. 

arg 4  Up  to  three  8-bit  characters,  left-justified,  to  be  transmitted  when  an  output-reset  is  done 

on  the  terminal.  These  characters  arc  protocol-dependent  If  any  unusual  condition 
occurs,  including  input  of  a  byte  with  the  high-order  bit  on  from  the  network,  the  STY 
will  be  disconnected  from  the  Chaosnet  channel  and  the  user  will  be  interrupted.  It  is 
illegal  to  do  I/O  on  any  of  the  involved  channels  without  disconnecting  them  from  each 
other  first 

The  CHAOSQ  system  call  allows  the  ATSIGN  CHAOS  program,  described  below,  to  peek  at 
the  queue  of  pending  RFC’s.  It  takes  one  argument,  which  is  the  address  of  a  126-word  buffer. 
T  he  first  RFC  packet  on  the  queue  is  copied  into  this  buffer  and  moved  to  the  end  of  the  queue. 
If  the  queue  is  empty,  the  system  call  takes  the  error  return. 

8.2  Utility  Programs 

ITic  K  mode  in  the  :PEEK  command  gives  one  line  of  information  for  each  Chaosnet 
connection  in  existence  on  the  local  machine,  lists  the  number  of  packet  butlers  in  existence  and 
free,  and  lists  any  queued  RFC’s  (sec  the  following  section).  Packet  buffers  arc  dynamically 
allocated  in  groups  of  8  from  system  memory.  Packet  buffers  in  existence  and  not  free  may  be  in 
use  to  contain  packets  being  transmitted  to  or  received  from  the  hardware,  unreceipted  output 
packets,  or  input  packets  not  yet  mad  by  the  user  program. 

The  information  about  a  Chaosnet  connection  printed  by  PEEK  consists  of: 

IDX  The  connection  index  number  (not  including  the  uniqui/ation  bits). 

USR  The  user  index  or  ITS  job  number  of  the  user  process  which  owns  the  connection. 

IJNAME 

JN/VME  I  he  name  of  the  user  process  which  owns  the  connection. 

STATE  The  stale  of  the  connection.  This  is  one  of  the  states  listed  in  section  4.6,  page 

25.  abbreviated  to  six  characters.  IOWI.VL  means  the  foreign  piolinol  slate. 

IBF  Hie  number  of  input  packets  buffered  and  available  to  be  lead  by  the  user 

process. 

PHF  The  number  of  input  packets  buffered  hut  not  set  (nailable  to  the  user  process 

because  they  arc  out  of  order.  Some  e.uliri  p.akels  are  missing;  when  they  arrive 
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these  packets  will  become  available. 

NOS  The  number  of  output  "slots"  available  in  the  window.  The  user  process  may 

send  this  many  packets  before  it  will  have  to  wait  for  an  acknowledgement. 

ACK  The  number  of  received  packets  which  should  be  acknowledged  but  which  have 

not  yet  been.  This  will  not  stay  non-zero  for  more  than  a  half  second,  since  if  it 
is  non-zero  an  SI'S  will  be  transmitted, 

R  WIN  The  window  size  for  the  incoming  half  of  this  connection, 

WIN  T  The  window  size  for  the  outgoing  half  of  this  connection. 

FOREIGN  ADDR 

ITic  host  name  and  index  number  of  the  other  end  of  this  connection.  The  = 
command  switches  between  host  names  and  host  numbers. 

FLAG  One  or  more  single-letter  flags  indicating  special  things  about  the  connection.  The 

following  Hags  exist: 

C  The  connection  is  half-closed  (one  of  its  I/O  channels  has  been  closed  and 
die  other  remains  open). 

F  The  connection  is  turned  "off’  as  far  as  die  interrupt  side  of  die  NCP  is 
concerned.  No  packets  will  be  received  or  transmitted. 

I  'The  connection  has  an  input  buffer  for  stream  (non-paeket)  input. 

O  The  connection  has  an  output  buffer  for  stream  (non-packet)  output. 

S  An  S  I  S  packet  needs  to  be  sent. 

T  The  connection  is  connected  to  a  SIT.  In  other  words  it  is  an  incoming 

Telnet  or  Supdup  connection  and  the  system  is  providing  the  data  transfer 

between  the  connection  and  the  pseudo  terminal. 

'The  :CHASTA  command  is  a  long-winded  version  of  the  above.  It  prints  several  lines  of 
information  about  each  connection  that  exists,  including  the  number  of  the  next  packet  to  be 
given  to  the  user,  die  number  of  the  next  packet  to  be  output  by  die  user,  and  the  number  of 
the  last  packet  acknowledged  in  each  direction. 

ITic  :CHARFC  command,  given  a  host  name  and  a  contact  name  in  the  command  line,  will 

open  a  connection  and  print  whatever  comes  back  (refusal,  simple  transaction,  or  any  data  that 

emerge  from  a  stream  connection).  The  contact  name  may  of  course  be  followed  by  a  space  and 
arguments.  This  command  can  be  useful  in  connection  with  the  STATUS  protocol,  to  sec  if  a 
host  is  up  (it  will  print  its  name  followed  by  some  garbage  characters),  and  in  connection  with 
the  PULSAR  protocol,  to  turn  pulsars  on  and  off. 

The  :CHATST  command  provides  a  vaiielv  of  simple  Chaosnet  manipulating  commands.  Run 
it  and  type  ?  for  a  list  of  the  commands.  I  he  II  (liostat)  command  may  be  die  most  useful;  it 
uses  the  STATUS  protocol  to  gel  mclciing  information  from  a  host  and  prims  it  nicely. 

T  he  HOST  command  given  the  name  of  a  host  in  dnNcoinniand  line,  looks  up  that  host  in 
the  system  host  table  am!  prints  a  hat  i-.  i-noy.  n  about  it,  ii\!mliug  its  mimetic  addir*.  I  his 
works  for  hosts  on  ill  nelwoiks.  I  lie  ,(  IIA1AU  loinmaiul  pinXs  a  table  of  all  li  e  hosts  on 
(  haosnel.  x 
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8.3  Server  Programs 

When  an  RFC  is  received  for  a  contact  name  for  which  there  is  no  outstanding  LSN,  the 
RFC  packet  is  saved  on  a  pcnding-RFC  queue  and  a  new  process  is  created  and  made  to  run  the 
program  in  the  file  SYS:ATSIGN  CHAOS.  This  program  uses  the  CHAOSQ  system  call  to  find 
out  the  contact  name  of  the  RFC.  The  contact  name  name  if,  truncated  to  six  characters  if  it  is 
longer.  If  a  file  named  DSK:DEVICE;CHAOS  name  exists,  that  file  contains  the  desired  server 
program;  it  is  loaded  into  the  server  process.  When  die  server  process  is  started,  register  0 
contains  the  contact  name  in  sixbit  and  channel  1  is  still  open  to  the  program  file.  The  server 
program  must  do  a  listen  for  its  contact  name,  open  the  connection,  log  in,  and  so  forth. 

Thus  a  server  for  a  new  protocol  can  be  added  simply  by  putting  a  link  on  the  DEVICE 
directory.  This  directory  is  also  used  for  Arpanet  servers  and  for  ITS  I/O  device  servers. 

If  no  file  is  found,  a  file  named  DSK:DEVICE;CHAOS  DFAULT  is  loaded  if  it  exists.  If  it 
does  not  exist  cither  (which  is  normally  the  ease)  the  RFC  is  ignored  and  the  server  process  kills 
itself.  After  a  while  the  system  will  refuse  the  RFC  by  sending  back  a  CI.S  unless  someone 
comes  along  and  listens  for  it. 

8.4  Subroutine  Packages 

The  file  SYSTEM;CHSDEF  >  can  be  .INSRT’cd  into  a  Midas  program  to  define  symbols  for 
die  format  of  a  packet,  die  packet  opcodes,  and  die  states  of  a  connection.  The  symbol  prefixes 
arc  %CO  for  opcodes,  %CS  for  states,  $CPK  for  packet-format  byte-pointers,  and  %CP  for 
packet- format  values. 

The  file  SYSENG;NETWRK  >  can  be  .INSRT’cd  into  a  Midas  program  to  provide  a  library  of 
subroutines  for  opening  connections,  listening  for  requests  for  connection,  analyzing  network 
errors  and  printing  useful  messages  to  the  user,  and  accessing  the  host-name  table 
(SYSBIN;HOSTS2).  All  system  programs  that  use  the  Chaosnet  do  so  with  the  aid  of  these 
subroutines.  NETWRK  supports  both  Chaosnet  and  Arpanet.  Documentation  is  provided  in 
omments  at  the  beginning  of  the  file. 
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9.  The  TOPS-20/TENEX  Implementation 

A  Chaosnet  connection  is  represented  by  a  JFN  obtained  from  die  CHA:  device.  The 
standard  I/O  operations  can  be  performed  on  such  a  JFN,  in  which  case  the  system  will  open  a 
Chaosnet  stream  connection  and  transfer  8-bit  bytes  in  both  directions.  When  a  Chaosnet 
connection  is  used  in  this  way.  it  is  compatible  with  the  rest  of  the  TOPS-20  file  and  I/O  system. 

Alternatively,  special  operations  can  be  used  to  send  and  receive  packets  and  do  other 
Chaosnet-specific  operations  on  a  Chaosnet  JFN.  These  arc  described  below. 

For  more  information,  see  [CPR]. 


9.1  Opening  Connections 

A  (potential)  Chaosnet  connection  is  represented  by  a  JFN.  When  the  JFN  is  opened,  an 
actual  Chaosnet  connection  is  created.  The  GTJFN  syntax  is  as  follows: 

The  device  name  is  CHA:.  The  filename  is  the  symbolic  name  or  octal  number  of  the  host  at 

the  other  end  of  the  connection,  or  a  null  string  if  it  is  desired  to  listen  for  an  incoming  Request 

For  Connection  rather  than  initiating  a  connection.  The  extension  (filctypc)  is  normally  the 
contact  name;  some  special  cases  arc  described  below.  Use  of  *  names  and  JFN  stepping  is  not 
permitted.  The  directory,  generation  (version)  number,  and  semicolon  attributes  arc  ignored  if 
present. 

When  the  JFN  is  opened  (with  OPENF),  normally  the  system  will  wait  for  the  connection  to 
open  up;  a  user  connection  (nonblank  filename)  will  wait  for  a  response  to  be  returned  to  its 
RFC,  and  a  server  connection  (blank  filename)  will  wait  for  an  RFC  to  come  in  to  its  contact 
name.  If  an  RFC  is  refused  or  the  foreign  host  is  not  up,  OPENF  will  return  an  error.  If  data 

mode  6  or  7  is  used  with  OPENF,  it  will  return  immediately,  without  waiting  for  tine  connection 

to  open.  This  is  useful  if  you  want  to  open  several  Chaosnet  connections  simultaneously,  or  if 
you  want  to  determine  the  reason  for  failure  if  the  connection  does  not  open;  if  die  normal  data 
mode  0  OPENF  fails,  the  operating  system  will  not  let  you  read  the  CLS  packet  nor  do  the 
.MOERR  operation  (described  below). 

There  arc  a  number  of  special  eases  in  die  GTJFN  syntax.  If  the  extension  is  a  null  string, 
then  the  contact  name  is  specified  by  OPENF  rather  than  by  GTJFN;  AC3  contains  the  number 
of  characters  in  the  contact  name  in  the  left  half,  and  die  address  of  die  contact  name  in  die 
right  half.  In  listening  mode  (the  filename  is  a  null  string),  then  if  the  extension  is  also  null,  tliis 
JFN  will  listen  to  any  RFC  that  is  not  otherwise  serviced.  Privileges  arc  required  and  only  one 
job  at  a  time  can  do  this.  This  mechanism  is  used  by  a  system  server  process.  If  the  filename  is 
null  and  die  extension  is  a  hyphen,  the  JFN  is  put  in  a  special  mode  for  simple  transactions; 
packet-level  I/O  may  be  used  to  transmit  any  number  of  RFCs  and  receive  any  response  packets 
(A  NS,  FWI  ),  I  OS,  or  CI  S). 

When  a  JFN  is  closed  with  CLOSF,  if  it  has  an  open  connection  the  end  of  data  protocol  is 
used  (an  IOI  packet  is  transmitted  and  its  acknowledgement  is  awaited),  and  then  a  CIS  packet 
is  tiaiv  uiiitcd.  (Ihi>  is  not  completely  implemented  \et;  cuircntly  no  I  OF  is  sent,  and  .MOEOF 
(\<T  below)  mu  t  he  used.)  II  the  JIM  i**  in  the  Up< Kcieiu'd  Male,  the  KIT  is  i eluded  bv 
sending  a  C  i  S. 
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9.2  Stream  Input  and  Output 

ITic  normal  I/O  JSYScs  (BIN,  BOUT,  SIN.  SOUT)  work  on  Chaosnet  JFNs.  When  the 
connection  was  created  by  listening,  doing  I/O  to  it  automatically  accepts  it  first  (sending  an 
OPN),  The  input  and  output  data  arc  transmitted  as  8-bit  bytes  in  standard  data  packets  (opcode 
200).  On  input,  if  an  HOF  packet  is  encountered  the  standard  end-of-file  action  occurs.  If  a  CLS 
or  I, OS  is  encountered,  or  the  connection  is  in  a  bad  suite,  an  error  is  signalled.  The  message 
from  the  CHS  or  LOS  may  be  picked  up  with  .MOERR  (see  below). 

On  TOPS-20,  but  not  Tcncx,  the  SIBE,  SOBE,  DIBE,  DOBE,  SINR,  and  SOUTR  JSYSes 
may  be  used.  The  latter  two  treat  each  packet  as  a  separate  record. 

'The  OPENF  byte  size  may  be  cither  7  or  8.  With  a  byte  size  of  8,  the  raw  Chaosnet  data 
bytes  arc  transmitted.  With  a  byte  size  of  7,  the  system  converts  between  the  ASCII  code  it  uses 
normally  and  the  Lisp  Machine  character  set,  which  is  standard  on  Chaosnet.  (This  is  not  yet 
implemented;  currently  a  byte  size  of  7  will  be  accepted  but  will  behave  the  same  as  8.) 

9.3  Packet  Input  and  Output 

It  is  possible  to  do  packet-level  input  and  output  and  to  deal  directly  with  the  details  of  the 
Chaosnet  protocol  by  using  the  special  operations  described  in  the  following  section.  Note  that 
stream  I/O  and  packet  I/O  should  not  be  mixed  in  the  same  connection,  unless  you  know  exactly 
what  you  are  doing,  since  you  can  get  your  data  out  of  order. 


9.4  Special  Operations 

GDSTS  returns  device-dependent  status.  AC2  returns  the  state  of  the  connection,  and  AC3 
returns  the  number  of  packet  slots  available  in  the  output  window  in  the  left  half,  and  the 
number  of  available  input  packets  in  the  right  half.  The  symbolic  names  for  the  connection  states 
arc  as  follows: 

.CSCLS  TTie  connection  is  closed  (or  was  never  opened). 

CSLSN  The  connection  is  listening  for  an  RFC. 

.CSRFC  An  RFC  has  been  received  by  a  listening  connection. 

C3RFS  An  RFC  has  been  sent. 

.CSOPN  The  connection  is  open. 

.CSLOS  The  connection  has  been  broken  by  a  LOS  packet. 

.CSINC  The  connection  has  been  broken  by  Incomplete  Transmission  (no  response  from 

the  other  end  for  a  long  lime). 

.CSPRF  This  is  the  "permanent  RFC"  stale  which  is  entered  by  GTJFN  with  a  null 

filename  and  an  extension  of  just  a  hyphen. 

MTOPR  performs  a  variety  of  special  operations,  with  the  JFN  in  ACl,  one  of  the  follow  ing 
lonction  codes  in  AC?,  and  an  nrpimenl  and/or  tclurn  value  in  AC3. 

.MOF’KS  Send  a  packet.  AC3  contains  the  address  of  the  first  word  of  the  packet.  An 

enor  return  is  taken  if  the  connection  is  in  a  bail  slate  for  the  kind  of  packet 
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.MOPKR 

.MOOPN 

.MOSND 

.MOEOF 

.MONOP 

.MOERR 


.MOACN 


.MOSWS 

.MORWS 

.MOAWS 

.MOUAC 

.MOFHS 

.MOSIZ 

.MOSRT 


being  transmitted.  This  will  wait  for  space  to  be  available  in  the  window. 

Receive  a  packet.  AC3  contains  the  address  of  a  126-word  buffer  in  which  the 
packet  is  to  be  stored.  This  will  wait  until  an  input  packet  arrives. 

Accept  a  Request  for  Connection.  Error  if  the  connection  is  not  in  the  RFC- 
received  state. 

Force  out  any  buffered  stream  output. 

Force  out  any  buffered  stream  output,  then  send  an  HOF  packet. 

Force  out-  any  buffered  stream  output,  then  wait  for  it  to  be  transmitted  and 
acknowledged.  (This  is  not  a  "no  op",  but  .MONOP  is  the  system  standard  name 
for  tiiis  operation.) 

Returns  the  error  message  from  a  received  CLS  or  UOS  packet.  An  error  is 
signalled  if  no  error  message  is  available.  AC3  is  a  string  pointer  to  where  to  put 
the  error  message:  it  is  updated  to  point  at  the  terminating  null  character  which 
makes  the  message  an  ASCI/  string. 

Assigns  PS1  (interrupt)  channels.  The  left  half  of  AC3  is  the  channel  number  for 
output  interrupts,  and  the  right  half  is  the  channel  number  for  input  and  state- 
change  interrupts.  Specifying  -1  as  a  channel  number  disables  interrupts.  Output 
interrupts  arc  signalled  when  the  window  is  full  and  then  an  acknowledgement  is 
received  which  makes  some  space  so  that  more  packets  may  be  output.  Input 
interrupts  arc  signalled  when  the  state  changes,  and  when  there  arc  no  input 
packets  available  and  then  a  packet  is  received. 

Sets  the  receive  window  size  from  AC3. 

Returns  the  receive  window  size  in  the  left  half  of  AC3  and  the  transmit  window 
size  in  the  right  half. 

Returns  the  available  space  in  the  transmit  window  in  AC3. 

Returns  the  number  of  unacknowledged  output  packets  in  AC3. 

Returns  the  foreign  host  number  in  AC3. 

Returns  the  maximum  packet  si/c  in  bytes  in  AC3.  This  can  be  smaller  than  the 
Chaosnet  standard  (488)  on  machines  encumbered  with  an  RSX20F  front  end. 

Sets  the  RFC  timeout  period  in  milliseconds  from  AC3.  The  maximum  is  262 
seconds. 


9.5  Utility  Programs 

There  are  two  Chaosnet  utility  programs,  both  named  CHASTA.  One  prints  one  line  for  each 
connection  (hat  exists,  giving  its  stale,  number  of  input  and  output  packets,  who  it  is  connected 
to,  etc.  The  other  prints  the  STATUS  protocol  information  for  every  host  on  the  network, 
including  the  host  name,  when  it  was  last  up,  and  its  packet  throughput  and  emu*  mints.  This 
information  is  maintained  by  a  system  daemon  prtHjess. 
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9.6  Server  Programs 

When  an  RFC  is  received  for  contact-name,  if  no  process  is  listening  for  contact-name  and 
the  file  SYSTEM:CHAOS.cc>/j/<K7-ww«e  (or  DSK:<SYSTEM>CHAOS.coh/<k'/-/i<wic  on  Tcncx)  exists, 
the  server  program  contained  in  that  file  is  run.  'ITic  server  program  should  open  CHA\. contact- 
name.  This  is  implemented  by  the  CHARFC  program  which  runs  as  a  daemon  job  and  opens 
CHA:.,  the  magic  name  which  gets  a  copy  of  all  unclaimed  RFCs.  Normally  the  server  program 
is  run  in  a  freshly-created  job,  and  may  log  in  if  it  wishes,  but  if  the  file  is  marked  as  ephemeral 
(the  ";E"  attribute),  it  is  run  in  a  subfork  of  the  CHARFC  job.  Ephemeral  servers  should  be 
used  for  protocols  that  don’t  involve  a  long-term  connection. 

The  TELNET  and  SUPDUP  servers  attach  their  Chaosnet  connection  directly  to  an  NVT,  just 
as  the  corresponding  Arpanet  servers  do. 

When  the  system  starts  up.  the  file  SYSTEM:HOSTS2.BIN  (or  DSK:<SYSTEM>HOSTS2.BIN 
on  Tcncx)  is  read  in  and  used  to  initialize  the  host  name  table  inside  the  system  used  by  GTJFN. 
1’his  is  the  1TS/TOPS-20/W ATI’S  standard  multi-network  host  table. 
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10.  The  Lisp  Machine  Implementation 

Lisp  Machine  Chaosnet  support  consists  of  a  set  of  Lisp  functions  and  data-structurc 
definitions  in  the  chaos:  package.  There  arc  three  important  data  structures.  A  conn  represents 
a  connection.  A  pkt  represents  a  packet.  A  stream  is  a  standard  I/O  stream  which  transmits  to 
and  receives  from  a  connection.  The  details  of  these  data  structures  arc  described  later. 

There  are  two  processes  which  belong  to  the  Chaosnet  NCR.  The  receiver  process  looks  at 
packets  as  they  arrive  from  die  network.  Control  packets  arc  processed  immediately.  Data  packets 
arc  put  on  the  input  packet  queue  of  the  connection  to  which  they  are  directed.  The  background 
process  wakes  up  periodically  to  do  retransmission,  probing,  and  certain  "background  tasks"  such 
as  starting  up  a  server  when  an  RFC  arrives  and  processing  "connection  interrupts"  (described 
below). 

10.1  Opening  and  Closing  Connections 

10.1.1  User-Side 

chaos :  connect  host  contact-name  &optiona1  window-size  timeout 

Opens  a  stream  connection,  and  returns  a  conn  if  it  succeeds  or  a  string  giving  the 

reason  for  failure,  host  may  he  a  number  or  the  name  of  a  known  host,  contact- name  is 

a  string  containing  tiie  contact  name  and  any  additional  arguments  to  go  in  die  RFC 

packet.  If  window-size  is  not  specified  it  defaults  to  13.  If  timeout  is  not  specified  it 

defaults  to  600  (ten  seconds). 

chaos: simple  host  contact-name  ^optional  timeout 

faking  arguments  similar  to  those  of  chaos:connect,  this  performs  the  user  side  of  a 
simple-transaction.  The  returned  value  is  either  an  ANS  packet  or  a  string  containing  a 
failure  message.  The  ANS  packet  should  be  disposed  of  (using  chaos:return  - pkt,  see 
below)  when  you  arc  done  with  it. 

chaos : remove-conn  conn 

Makes  conn  null  and  void.  It  becomes  inactive,  all  its  buffered  packets  arc  freed,  and  the 
corresponding  Chaosnet  connection  (if  any)  goes  away. 

chaos: close  conn  Aoplional  reason 

Closes  and  removes  die  connection.  If  it  is  open,  a  CI  S  packet  is  sent  containing  the 
string  reason.  Don't  use  this  to  reject  RFC’s;  use  chaos:reject  for  that. 

chaos : open-foreign-connection  host  index  Aoptional  pkt-allocation  distinguished-port 

Creates  a  conn  which  may  be  used  to  transmit  and  receive  foreign  protocols  encapsulated 
in  I  INC  park  els.  host  and  index  are  the  destination  address  for  packets  sent  with 
chnor»:snn<l  one  pkt.  pkiallouiiion  is  the  "window  si/e",  i.e.  the  maximum  number  of 
input  packets  w Ilk  li  may  be  bulhnd.  Ii  defaults  to  10.  II  ihsimnucdu  d  junt  is  supplied, 
the  Deaf  index  is  set  to  it.  I  his  is  noesvtry  fbi  piototoL  wbi<  Ii  define  ihe  mrininps  of 
paitivular  index  numbers 
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10.1. 2  Server-Side 

chaos: listen  contact-name  &optional  window-size  wait-for-rfc 

Waits  for  an  RFC  for  the  specified  contact  name  to  arrive,  then  returns  a  conn  which 
will  be  in  the  RFC  Received  state.  If  window-size  is  not  specified  it  defaults  to  -13.  If 
wait-for-rfc  is  specified  as  nil  (it  defaults  to  t)  then  the  conn  will  be  returned  immediately 
without  waiting  for  an  RFC  to  arrive. 

chaos  :server-al  1st  Variable 

Contains  an  entry  for  each  server  which  always  exists.  When  an  RFC  arrives  for  one  of 
these  servers,  the  specified  form  is  evaluated  in  the  background  process;  typically  it 
creates  a  process  which  will  then  do  a  chaos:listen.  Use  the  add -initialization  function 
to  add  entries  to  this  list. 

chaos: accept  conn 

conn  must  be  in  the  RFC  Received  state.  An  OPN  packet  will  be  transmitted  and  conn 
will  enter  the  Open  state.  If  the  RFC  packet  has  not  already  been  read  with  chaos:get- 
next-pkt,  it  is  discarded.  You  should  read  it  before  accepting  if  it  contains  arguments  in 
addition  to  the  contact  name. 

chaos: reject  conn  reason 

conn  must  be  in  the  RFC  Received  state.  A  CLS  packet  containing  the  string  reason  will 
be  sent  and  conn  will  be  removed. 

chaos: answer-string  conn  string 

conn  must  be  in  the  RFC  Received  state.  An  ANS  packet  containing  the  string  string  will 
be  sent  and  conn  will  be  removed. 

chaos: answer  conn  pkt 

conn  must  be  in  the  RFC  Received  state,  pkt  is  transmitted  as  an  ANS  packet  and  conn 
is  removed.  Use  this  function  when  the  answer  is  some  binary  data  rather  titan  a  text 
string. 

chaos:fast-answer-str1ng  contact-name  string 

If  a  pending  RFC  exists  to  contact-name ,  an  ANS  containing  siring  is  sent  in  response  to 
it  and  t  is  returned.  Otherwise  nil  is  returned.  This  function  involves  the  minimum 
possible  overhead.  No  conn  is  created. 


10.2  Connection  States 
chaos: state  conn 

Returns  the  current  state  of  the  connection,  as  one  of  the  following  symbols: 

chaos.inactive-state  A  conn  which  does  not  correspond  to  any  Chaosnet 

connection. 

chaos:open  -state  An  open  connection. 

clwos:rfc- sent  state  An  RFC  has  been  transmitted  and  no  response  has  yet 

been  received. 
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chaos:answered-state  An  ANS  has  been  received, 

chaosxls- received -state  A  CLS  has  been  received, 

chaos:  los- received -state  A  LOS  has  been  received. 

chaos:host-down-state  The  connection  is  in  the  Incomplete  Transmission  state; 

communications  with  the  foreign  host  have  broken  down. 

chaos:listening -state  A  LSN  has  been  "transmitted”  and  the  connection  is 

awaiting  an  RFC. 

chaos:rfc- received -state  An  RFC  has  been  received  while  listening  and  has  not  yet 

been  responded  to. 

chaos:foreign -state  The  connection  is  being  used  with  a  foreign  protocol 

encapsulated  in  UNC  packets. 

chaos: wait  conn  state  timeout  &optional  whostate 

Waits  until  the  state  of  conn  is  not  the  symbol  state ,  or  until  timeout  60ths  of  a  second 
have  elapsed.  If  the  timeout  occurs,  nil  is  returned;  otherwise  t  is  returned,  whostate  is 
the  process  state  to  put  in  the  who-linc;  it  defaults  to  "net  wait". 


10.3  Stream  Input  and  Output 
chaos: stream  conn 

Creates  a  bidirectional  stream  which  accesses  conn ,  which  should  be  open  as  a  stream 

connection,  as  8-bit  bytes.  In  addition  to  the  usual  I/O  operations,  die  following  special 

operations  arc  supported: 

:force-output  Any  buffered  output  is  transmitted.  Normally  output  is  accumulated  until 
a  full  packet’s  worth  of  bytes  arc  available,  so  diat  maximum-size  packets 
arc  transmitted. 

:finish  Waits  until  either  all  packets  have  been  sent  and  acknowledged,  or  the 

connection  ceases  to  be  open.  If  successful,  returns  t;  if  the  connection 
goes  into  a  bad  slate,  returns  nil. 

:eof  Forces  out  any  buffered  output,  sends  an  HOF  packet,  and  docs  a  :finish. 

:clear-eof  Allows  you  to  read  past  an  HOF  packet  on  input.  Kach  :tyi  will  return  nil 

or  signal  the  specified  eof  error  until  a  xlear-eof  is  done. 

:close  Send  a  CLS  packet  and  remove  die  connection. 

10.4  I’nckcl  Input  and  Output 

Input  and  output  on  a  Chaosnet  connection  can  he  done  at  die  whole-packet  level,  using  the 
functions  in  this  section.  A  packet  is  rcpiesenicd  by  a  pkt  data  structure.  Allocation  of  pkts  is 
controlled  hv  the  system;  each  pkt  that  it  gives  you  must  be  given  back.  There  are  functions  to 
convert  between  pkts  and  strings.  A  pkt  is  an  art  16h  array  containing  the  packet  header  and 
data;  the  r;haos:iirsl  data  word  in  pkt’th  element  of  the  array  is  the  first  Ifi-bit  data  word.  The 
leader  of  a  pkt  contains  a  number  of  holds  mod  by  the  system. 
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chaos :pkt-opcode  pkt 

Accessor  for  the  opcode  field  of  pkt'%  header.  For  each  standard  opcode  a  symbol  exists 
in  the  chaos:  package,  consisting  of  the  standard  3-lctter  code  and  a  suffix  of  "-op", 
chaos:rfc-op  for  example.  Ilie  value  of  the  symbol  is  the  numeric  opcode. 

chaos :pkt-nbytes  pkt 

Accessor  for  the  number-of-data-bytes  field  of  pkt's  header. 

chaos:pkt-str1ng  pkt 

An  indirect  array  which  is  the  data  field  of  pkt  as  a  string  of  8'bit  bytes.  The  length  of 
this  string  is  equal  to  (chaos:pkt-nbytes  pkt), 

chaos  :$et-pkt-str1ng  pkt  &rcst  strings 

Copies  the  strings  into  the  data  field  of  pktt  concatenating  them,  and  sets  (chaos:pkt- 
nbytes  pkt)  accordingly. 

chaos :get-pkt 

Allocates  a  pkt  for  use  by  the  user. 

chaos : return-pkt  pkt 

Deallocates  a  pkt. 

Chaos :  send-pkt  conn  pkt  &optional  (opcode  chaos'dat- op) 

Transmits  pkt  on  conn,  pkt  should  have  been  allocated  with  chaos:get-pkt  and  then  had 
its  data  field  and  n-bytes  filled  in.  opcode  must  be  a  data  opcode  (200  or  more)  or  HOF, 
An  error  is  signalled,  with  condition  chaos:not- open -state,  if  conn  is  not  open. 

chaos :  send-strl ng  conn  &rcst  strings 

Sends  a  data  packet  containing  the  concatenation  of  strings  as  its  data, 

chaos : send-unc-pkt  conn  pkt  &optional  pkt-number  ack-number 

'Transmits  pkt ,  an  UNC  packet,  on  conn.  The  opcode,  packet  number,  and  acknowledge 
number  fields  in  the  packet  header  arc  filled  in  (the  latter  two  only  if  the  optional 
arguments  arc  supplied). 

chaos :may~transm1t  conn 

A  predicate  which  returns  t  if  there  is  any  space  in  the  window, 

chaos:  finish  conn  Aoptional  (whostote  MNet  Finish*’) 

Waits  until  either  all  packets  have  been  sent  and  acknowledged,  or  the  connection  ceases 
to  be  open,  if  successful,  returns  t;  if  the  connection  goes  into  a  had  state,  returns  nil. 
w/mfate  is  the  process  state  to  display  in  the  who  line  while  waiting. 

chaos :  gotnext-pkt  conn  ^optional  (no-h/wg-pnii) 

Returns  the  next  input  packet  from  conr.  When  you  arc  done  with  the  packet  you  must 
give  it  hack  to  the  system  with  chaosactum  pkt.  This  can  return  an  RFC,  fI  S,  or 
ANS  packet,  in  addition  to  data,  UNC,  ca*  I  Of  .  If  no  hung' p  is  t,  nil  will  he  ictumed 
if  there  are  no  packets  available  or  the  connection  is  in  a  had  state.  Otherwise  an  error 
will  he  signalled  if  the  connection  is  in  .1  had  slate,  with  condition  name  oh  uvvhost* 
down.  chiius:los  rrceivctf  state,  or  chans:rou<l  on  dosod  connection.  II  no  packets 
ate  available  and  nodmngp  is  nil,  chaos:get  next -pkt  will  wait  lor  packets  to  come  in 
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or  the  state  to  change.  The  process  state  in  the  who-line  is  "NETI". 


chaosrdata-avallable  conn 

A  predicate  which  returns  t  if  there  any  input  packets  available  from  conn . 


10.5  Connection  Interrupts 
chaos : Interrupt- function  conn 

This  attribute  of  a  conn  is  a  function  to  be  called  in  the  background  process  when  certain 
events  occur  on  this  connection.  Normally  this  is  nil,  which  means  not  to  call  any 
function,  but  you  can  use  setf  to  store  a  function  here.  Since  the  function  is  called  in 
the  Chaosnet  background  process,  it  should  not  do  any  operations  that  might  have  to  wait 
for  the  network,  since  that  could  permanently  hang  the  background  process. 

The  function’s  first  argument  is  one  of  the  following  symbols,  giving  the  reason  for  the 
"interrupt*'.  The  function’s  second  argument  is  conn.  Additional  arguments  may  be 
present  depending  on  the  reason.  The  possible  reasons  are: 

.input  A  packet  has  arrived  for  the  connection  when  it  had  no  input  packets 

queued.  It  is  now  possible  to  do  chaos:get-next-pkt  without  having  to 
wait.  There  are  no  additional  arguments. 

:output  An  acknowledgement  has  arrived  for  the  connection  and  made  space  in 

the  window  when  formerly  it  was  full.  Additional  output  packets  may 
now  be  transmitted  with  chaos:send-pkt  without  having  to  wait,  Tlicrc 
arc  no  additional  arguments. 

:change-of~state 

The  state  of  the  connection  has  changed.  The  third  argument  to  the 
function  is  the  symbol  for  the  new  state. 

chaos : readpkts  conn 

Some  interrupt  functions  will  want  to  look  at  the  queued  input  packets  of  a  connection 
when  they  get  a  ;input  interrupt.  chaos:read~pkts  returns  the  first  packet  available  for 
reading.  Successive  packets  can  be  found  by  following  chao$:pkt-link. 

chaos:pkt-11nk  pkt 

Lists  of  packets  in  the  NCP  arc  threaded  together  by  storing  each  packet  in  the 
chaos:pkt  link  of  its  predecessor.  The  list  is  terminated  with  nil. 


10.6  Information  and  Control 
chaos: host  data  ^optional  host 

host  may  he  a  number  or  a  known  host  name,  and  delimits  lo  the  local  host.  Two  values 
are  returned.  The  first  value  is  the  host  name  and  the  second  is  the  host  number.  If  the 
host  is  a  number  not  in  the  table,  ii  is  asked  its  name  using  the  STATUS  protocol:  if  no 
icsponse  is  received  the  name  "Unknown"  is  returned. 
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hot  tat  Arest  hosts 

Interrogates  the  specified  hosts,  or  all  known  hosts  if  none  arc  specified,  with  the 
STATUS  protocol  and  prints  the  results  in  columns  as  a  table. 

chaos : print-conn  conn  Aoptional  (shorn) 

Prints  everything  the  system  knows  about  the  connection.  If  short  is  nil  it  also  prints 
everything  the  system  knows  about  each  queued  input  and  output  packet  on  the 
connection. 

chaos : print- pkt  pkt  &optional  (short nil) 

Prints  everything  the  system  knows  about  the  packet,  except  its  data  field.  If  short  is  t, 
only  the  first  line  of  the  information  is  printed. 

chaos : print-all -pkts  pkt  &optional  (short t) 

Calls  chaos:print-pkt  on  pkt  and  all  packets  on  the  threaded  list  emanating  from  it 

chaos: status 

Prints  the  hardware  status. 

chaos: reset 

Resets  tiic  hardware  and  software  and  turns  off  the  network. 

chaos :assure-enab1ed 

Turns  on  the  network  if  it  is  not  already  on.  It  is  normally  always  on  unless  you  call  one 
of  these  functions. 


chaos:enab1e 

Resets  the  hardware  and  turns  on  the  network. 

chaos:d1sable 

Resets  the  hardware  and  turns  olf  the  network. 
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11.  The  VAX/VMS  Implementation 

This  describes  the  interface  to  Chaosnet  through  the  routines  in  the  "CHAOS. B32"  BUSS-32 
subroutine  package.  Definitions  of  standard  values  are  in  "NCPDFFS.R32".  Though  it  is  possible 
to  interface  to  the  NCT  at  the  VMS  I/O  level,  it  is  not  recommended  practice.  All  references  to 
Chaosnet  in  this  text  are  with  respect  to  die  subroutine  package,  and  not  VMS  QIO’s. 

A  Chaosnet  connection  is  represented  by  a  one  longword  "channel  number",  which  has  no 
direct  relationship  to  a  VMS  channel  number.  !lowe\er,  for  every  Chaosnet  channel  currently 
allocated,  there  is  an  associated  VMS  channel  maintained  by  the  subroutine  package. 

All  of  the  routines  described  below  arc  declared  "global". 

11.1  Opening  and  Closing 
par$e_ho$t  (host,  ret-host-num ) 

Parses  the  string  pointed  to  by  host  (which  points  to  a  standard  VMS  string  descriptor), 
and  stores  the  resulting  host  number  in  the  word  pointed  to  by  ret-host-num ,  Returns  a 
status  code. 

chaos_rf  c  (ret-ehan  host ,  contact-name ,  wait-time) 

Opens  a  new  Chaosnet  channel  and  sends  an  RFC.  ret-chan  is  a  longword  to  receive  the 
channel  number,  host  is  a  siring  acceptable  to  parse_host.  contact-name  is  a  pointer  to  a 
string  descriptor,  wait-time  is  either  zero,  w'hich  means  to  wait  indefinitely  for  a  response 
to  the  RFC,  or  a  pointer  to  a  quadword  block  acceptable  to  die  SSETIMR  system  service. 
A  status  code  is  returned,  which  will  be  SS$_TIMEOUT  if  the  routine  times  out. 

Chaos^lsn  (ret-chan,  contact-name ,  wait-time) 

Like  chaos_rfc,  but  "sends"  a  FSN  instead  of  an  RFC.  No  host  is  specified. 

chaos_accept  (chan  window,  rfc-arg,  ret-rfe-arg-size) 

Accepts  an  incoming  RFC,  The  connection  must  be  in  RFC-received  state,  window  is  the 
window  size,  rfc-arg  is  an  optional  string  descriptor  which  receives  die  argument  to  the 
RFC.  ret- rfc-arg- size  is  also  optional,  and  gets  the  argument's  length. 

chaos^ans  (chan  data,  wait-time) 

Sends  an  A  NS  packet  to  the  Chaosnet  channel,  data  points  to  a  string  descriptor,  wait- 
time  is  ignored.  A  status  code  is  returned,  and  if  an  error  occurs,  die  channel  is 
deassigned. 

chaos_close  (chan  reason) 

Closes  the  connection,  and  deassigns  the  channel,  reason  is  a  pointer  to  a  string 
dcM  iipior  of  a  string  to  he  included  in  the  C  I  S  packet. 
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chaoa.asalgn  ( ret-chan ) 

Assigns  a  Chaosnet  channel,  and  stores  it  in  the  longword  pointed  to  by  ret- chan.  This 
routine  allocates  a  VMS  channel.  A  status  code  is  returned. 

chaos.deasslgn  (chan) 

Given  a  Chaosnet  channel  previously  assigned  by  chaos. assign,  dcassigns  it  and  the 
associated  VMS  channel. 

11.2  Stream  Input  and  Output 

chaos_1n_char  (chan,  ret-char,  timeoul) 

Returns  the  next  character  from  the  channel  in  the  longword  pointed  to  by  ret-char. 
Waits  until  a  character  is  available  or  until  timeout,  whichever  comes  first  A  status  code 
is  returned. 

chaos_out_char  (chan,  char) 

Outputs  one  character.  Characters  arc  buffered  until  a  packet  fills  up  or  until  the  output 
is  forced  out  by  chaos_force_out.  A  status  code  is  returned. 

chaos. sout  (chan,  string) 

I. ike  repeated  calls  to  chaos_out_char:  sends  string  from  string  descriptor  pointed  to  by 
string. 

chaos_force_out  (chan) 

If  doing  serial  output,  and  a  partial  packet  is  buffered,  force  it  to  be  sent 
chaos.flnlsh  (chan) 

Does  a  chaos.force.out,  then  waits  for  all  packets  to  be  acknowledged  by  the  foreign 
end. 

chaos.eof  (chan) 

Sends  an  HOF  packet  after  forcing  out  any  buffered  output. 

1 1.3  Packet  Input  and  Output 

al  locato.pkt  (sue.  chan,  ret-pki) 

Allocates  a  packet  suitable  for  chaosjn.pkt  and  chaos_out_pkt.  Ihc  packet  can  hold 
up  to  size  hytes  of  data;  the  number  of  bytes  field  in  the  packet's  header  is  filled  in  from 
size,  ret-pkt  points  to  a  longword  lo  receive  a  pointer  to  the  packet.  A  status  code  is 
returned. 

doal locate.. pkt  (pkt) 

Returns  a  previously  allocated  packet  to  the  free  pool.  A  packet  may  be  reused,  since  the 
I/O  routines  do  not  deallocate  them,  as  long  as  the  I/O  is  being  done  synchronously. 
Returns  a  status  code. 
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chaos_out_pkt  (chan,  pkt,  cfn,  astadr ;  astprm) 

Outputs  pki  to  chan ,  waiting  if  there  is  no  window  room  available,  efn  is  the  event 
channel  to  use  for  waiting,  astadr  and  astprm  are  as  for  VMS  system  services;  an  AST' 
address  and  parameter,  respectively,  that  get  signalled  when  the  packet  is  read  by  the 
NCP.  chaos_out_pkt  returns  as  soon  as  there  is  space  in  the  window,  without  waiting 
for  die  NCP  to  finish  transmitting  die  packet. 

chaos_1n_pkt  (chan,  cfn,  pkt,  astadr,  astprm) 

Reads  the  next  input  packet,  whatever  opcode  it  may  be,  from  the  connection,  waiting 
indefinitely  if  dicrc  arc  no  input  packets,  cfn  is  the  event  channel  to  wait  on,  and  astadr 
and  astprm  arc  for  an  AST  to  be  delivered  when  the  read  completes,  chaosjn^pkt  docs 
not  return  until  the  read  completes.  A  status  code  is  returned. 

11.4  Checking  the  State 

chao$_xm1t_room  (chan,  wait) 

Returns  SS$_NORMAL  if  there  is  room  left  in  the  transmit  window.  Returns  an  error  if 
the  connection  went  into  a  bad  state.  If  wait  is  true,  and  there  is  no  room  left,  then 
chaos_xmit_room  waits  until  room  is  available,  if  there  is  no  room  left  and  wait  is  false, 
it  returns  SS$_EXQUOTA. 

chaos^state  (chan) 

Updates  die  state  of  die  Chaosnet  channel  via  a  request  U)  the  NCP.  Returns  a  status 
code.  To  check  die  state  of  the  connection,  first  call  this  routine  then  look  at  chan_state 
in  the  channel  block  described  below. 

chaos^walt  (chan,  old-state ,  timeout) 

Waits  until  die  channel  goes  out  of  the  specified  state  or  until  timeout  occurs.  Timeout  is 
either  zero  (no  timeout)  or  a  pointer  to  a  quadword  block  acceptable  to  $SETIMR.  A 
status  code  is  returned. 

Chaos_wa1  t„t1 1  (chan,  state,  timeout) 

Waits  until  the  channel  goes  into  the  specified  state  or  until  timeout  occurs.  Timeout  is 
cither  zero  (no  timeout)  or  a  pointer  to  a  quadword  block  acceptable  to  $SETIMR.  A 
status  code  is  returned. 

'Hie  channel  number  is  used  as  an  index  into  the  global  blockvcctor  channel,  defined  in  the 
"CHAOS. 11.12"  file.  Since  lil.lSS-32  docs  not  allow  the  field  definitions  to  be  global,  they  should 
be  copied  into  any  program  that  needs  to  look  inside  the  channel  blockvcctor.  The  most  useful 
fields  arc 

chan_state  One  of  the  state  codes  defined  below. 
chan_sta_Jxw  The  window  size  in  the  liansmit  direction. 

chan_sta_rxw  The  window  size  in  the  receive  direction. 

chan_sta.,txwa  The  number  of  packet  slots  available  in  the  transmit  window. 

chan_sta,  rxav  The  number  of  input  packets  .nailable. 
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The  states  arc  as  follows: 

conn_st_closed  (0)  Connection  closed  by  a  CLS  packet. 

conn_st_rfcrcv(1)  RFC  received  by  listening  connection. 

conn_st_rfcsnt  (2)  RFC  sent,  no  response  yet. 

conn_st_open  (3)  Connection  open. 

conn_st_los  (4)  Connection  broken  by  a  LOS  packet. 

conn_st Jncom  (5)  Incomplete  transmission  (no  response  from  foreign  host). 

conn_st_new  (6)  Connection  newly  allocated. 

conn_st_lsn  (7)  Listening  for  an  incoming  RFC. 

connstfull (%0’400’)  This  bit  is  set  when  the  transmit  window  is  full.  Usually,  the 
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12.  The  Unix  Implementation 

The  Unix  implementation  of  Chaosnet  works  on  both  pdpll  Unix  and  VAX  Unix. 

The  network  may  be  accessed  in  four  different  ways.  A  Chaosnet  stream  connection  may  be 
opened  to  a  host  and  a  contact  name,  and  then  standard  Unix  I/O  may  be  done  over  the 
connection.  A  Chaosnet  connection  may  be  accessed  at  the  packet  level  (howcvcr,  this  is  not  yet 
implemented).  A  Chaosnet  stream  connection  may  be  made  into  a  Unix  tty;  this  is  how  the 
TELNET  server  works.  A  subtree  of  one  Unix  host’s  file  system  may  be  mapped  into  another 
Unix  host’s  file  system,  with  the  intermediate  Chaosnet  invisible  to  programs  operating  on  the 
remote  files. 

You  get  access  to  Chaosnet  by  opening  a  file  pathname  which  includes  a  special  file  whose 
major  device  is  Chaosnet.  The  minor  device  number  of  that  special  file,  together  with  its  name 
and  any  additional  pathname  components  after  it,  are  used  to  determine  the  host,  RFC  contact 
name,  and  RFC  arguments.  Remote  file  access  is  implemented  by  special  files  which  map  into 
the  desired  host  with  contact  name  ftpread  or  ftpwrite.  The  remaining  pathname  after  the  special 
file  is  passed  along  and  used  as  a  pathname  on  the  remote  host. 

The  8-bit  Unix  minor-device  number  is  divided  up  into  several  fields  which  control  details  of 
what  happens  when  you  open  a  Chaosnet  special  file.  The  current  division  is  as  follows: 

bits  6-3  Host  specifier.  Small  numbers  arc  indices  in  a  site-dependent  table  of  hosts  which  are 
particularly  useful  to  connect  to.  'This  is  used  primarily  for  the  remote  file-system 
facility.  Otherwise  this  is  one  of: 

015  The  host  number  (in  decimal)  is  read  from  the  name  of  the  special  file. 

016  The  host  number  (in  decimal)  is  read  from  the  next  pathname  component 
after  the  special  file. 

017  Activates  one  of  a  number  of  special  features  selected  by  bits  2-0.  See  below. 

bits  2-0  If  the  host  specifier  is  not  017,  this  is  a  contact  name  specifier.  Small  numbers  are 
indices  in  a  site-dependent  table  of  useful  contact  names.  This  is  used  primarily  for 
the  remote  file-system  facility.  Otherwise  this  is  one  of: 

6  Read  the  contact  name  from  the  name  of  the  special  file. 

7  Use  the  rest  of  the  pathname,  after  the  special  file,  as  the  contact  name  and 
RFC  arguments. 

When  both  the  host  number  and  the  contact  name  are  read  from  the  pathname,  the 
host  number  is  read  first.  Any  character  other  than  the  digits  0  through  9  serves  to 
separate  them. 

If  the  host  specifier  is  017,  this  is  instead  one  of  the  following: 

0  Pick  up  unmatched  incoming  KFCs.  Only  one  process  at  a  lime,  per  system, 
may  open  this  device.  The  ioctl  operation  chiounext  (see  below)  is  used 
with  this  device. 

1  1  isten  mode.  The  rest  of  the  pathname,  alter  the  special  file,  is  the  contact 

name  listened  to.  Hus  will  wait  until  an  Kit.’  tomes  in  to  that  pathname.  A 


l)SK:MOON;AMm:«  107 


15-JUN-81 


ITic  Unix  Implementation 


58 


Chaosnet 


typical  pathname  would  be  "/dev/chlisten/myprotocol". 

2  I.istcn-crror  mode.  Same  as  above,  but  if  there  is  no  pending  RFC  to  the 
contact  name,  this  will  return  an  error  rather  than  waiting  for  one. 

3  Packet  mode.  This  is  not  implemented  yet. 

bit  7  Specifics  that  this  Chaosnet  connection  should  be  wired  to  a  tty. 

When  a  Chaosnet  connection  is  wired  to  a  Unix  tty,  input  data  from  Chaosnet  appear 
as  keyboard  input  characters  on  that  tty.  Output  typed  on  the  tty  goes  out  on 
Chaosnet  as  data.  When  the  tty  is  hung  up  (logged  out),  the  Chaosnet  connection 
will  be  closed.  I/O  operations  done  to  the  Chaosnet  channel  will  be  done  to  the  tty 
instead,  except  for  the  special  ioctl  operations  given  below. 

When  a  connection  has  been  opened,  the  normal  Unix  I/O  operations  may  be  done  on  it.  8- 

bit  bytes  in  standard  data  packets  (opcode  200)  arc  used.  If  the  Chaosnet  connection  is  not  open, 

the  I/O  operations  will  return  an  error.  When  the  close  operation  is  performed,  if  the  Chaosnet 
connection  is  open  the  standard  F.OF  protocol  will  be  followed  (see  section  4.4,  page  24). 

The  following  operations  arc  supported  for  the  ioctl  system  call: 

fionread  Returns  the  total  number  of  data  bytes  in  the  available  input  packets.  This  is  the 
number  of  bytes  which  can  be  read  without  waiting. 

chiocflush  Forces  out  buffered  output.  Normally  stream  output  is  held  until  a  packet  is  filled 
up  or  2  seconds  have  elapsed. 

chiocrread  Returns  data  from  the  RFC  packet.  This  is  only  valid  on  a  connection  which  was 
created  by  listening  and  which  has  not  yet  been  read  from.  The  source  host  (2 
bytes)  is  returned,  followed  by  a  null-terminated  character  string  which  is  the 
contact  name  and  any  following  arguments. 

chioernext  This  is  only  valid  on  the  unmatchcd-RFC  connection,  and  is  the  only  ioctl 
operation  valid  on  it.  This  waits  until  an  unmatched  RFC  is  present,  and  then 
returns  its  contact-name  and  arguments  as  a  null-terminated  string.  The  system 
unmatchcd-RFC  process  uses  this  to  start  up  server  processes  as  RFCs  come  in. 
(Currently  this  mechanism  is  used  only  for  the  remote  file-system  servers.) 

chioetty  If  the  Chaosnet  connection  is  open,  and  is  not  already  wired  to  a  tty,  this  creates 

a  new  Unix  tty  and  wires  it  to  the  connection. 
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